[JSC] fix RETURN_IF_EXCEPTION() placement in ownPropertyKeys()
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2017-04-26  Caitlin Potter  <caitp@igalia.com>
2
3         [JSC] fix RETURN_IF_EXCEPTION() placement in ownPropertyKeys()
4         https://bugs.webkit.org/show_bug.cgi?id=171330
5
6         Reviewed by Mark Lam.
7
8         Ensure RETURN_IF_EXCEPTION() following invokation of the
9         filterPropertyIfNeeded() lambda.
10
11         * runtime/ObjectConstructor.cpp:
12         (JSC::ownPropertyKeys):
13
14 2017-04-26  Caitlin Potter  <caitp@igalia.com>
15
16         [JSC] Object.keys() must discard property names with no PropertyDescriptor
17         https://bugs.webkit.org/show_bug.cgi?id=171291
18
19         Reviewed by Yusuke Suzuki.
20
21         Proxy objects can produce an arbitrary list of property names from the
22         "ownKeys" trap, however the Object.keys() algorithm is required to
23         discard names which do not have a PropertyDescriptor. This also
24         applies to other uses of the EnumerableOwnProperties() algorithm
25         (https://tc39.github.io/ecma262/#sec-enumerableownproperties)
26
27         Related to https://bugs.chromium.org/p/v8/issues/detail?id=6290
28
29         * runtime/ObjectConstructor.cpp:
30         (JSC::ownPropertyKeys):
31
32 2017-04-25  Andy VanWagoner  <thetalecrafter@gmail.com>
33
34         Unhandled enumeration values in IntlDateTimeFormat.cpp
35         https://bugs.webkit.org/show_bug.cgi?id=171241
36
37         Reviewed by JF Bastien.
38
39         Added some missing cases of the UDateFormatField to partTypeString,
40         and made them conditional to the ICU version that added them.
41         This should remove the warnings that appear on platform builds using the
42         newer system ICU headers.
43
44         * runtime/IntlDateTimeFormat.cpp:
45         (JSC::IntlDateTimeFormat::partTypeString):
46
47 2017-04-25  Commit Queue  <commit-queue@webkit.org>
48
49         Unreviewed, rolling out r215476.
50         https://bugs.webkit.org/show_bug.cgi?id=171304
51
52         "It broke JSBench" (Requested by saamyjoon on #webkit).
53
54         Reverted changeset:
55
56         "[ES6]. Implement Annex B.3.3 function hoisting rules for
57         eval"
58         https://bugs.webkit.org/show_bug.cgi?id=163208
59         http://trac.webkit.org/changeset/215476
60
61 2017-04-25  Saam Barati  <sbarati@apple.com>
62
63         JSArray::isArrayPrototypeIteratorProtocolFastAndNonObservable is wrong because it does not do the necessary checks on the base object
64         https://bugs.webkit.org/show_bug.cgi?id=171150
65         <rdar://problem/31771880>
66
67         Reviewed by Sam Weinig.
68
69         This patch fixes a huge oversight from the patch that introduced
70         op_spread/Spread. The original patch did not account for the
71         base object having Symbol.iterator or getters that could
72         change the iterator protocol. This patch fixes the oversight both
73         in the C code, as well as the DFG/FTL backends. We only perform
74         the memcpy version of spread if we've proven that it's guaranteed
75         to be side-effect free (no indexed getters), and if the iterator
76         protocol is guaranteed to be the original protocol. To do this, we
77         must prove that:
78         1. The protocol on Array.prototype hasn't changed (this is the same as the
79         introductory patch for op_spread).
80         2. The base object's __proto__ is Array.prototype
81         3. The base object does not have indexed getters
82         4. The base object does not have Symbol.iterator property.
83
84         * dfg/DFGGraph.cpp:
85         (JSC::DFG::Graph::canDoFastSpread):
86         * dfg/DFGGraph.h:
87         * dfg/DFGSpeculativeJIT.cpp:
88         (JSC::DFG::SpeculativeJIT::compileSpread):
89         * ftl/FTLLowerDFGToB3.cpp:
90         (JSC::FTL::DFG::LowerDFGToB3::compileSpread):
91         * runtime/JSArray.cpp:
92         (JSC::JSArray::isIteratorProtocolFastAndNonObservable):
93         * runtime/JSArray.h:
94         * runtime/JSArrayInlines.h:
95         (JSC::JSArray::isIteratorProtocolFastAndNonObservable): Deleted.
96         * runtime/JSGlobalObject.h:
97         * runtime/JSGlobalObjectInlines.h:
98         (JSC::JSGlobalObject::isArrayPrototypeIteratorProtocolFastAndNonObservable):
99         (JSC::JSGlobalObject::isArrayIteratorProtocolFastAndNonObservable): Deleted.
100
101 2017-04-25  Mark Lam  <mark.lam@apple.com>
102
103         Array.prototype.slice() should ensure that end >= begin.
104         https://bugs.webkit.org/show_bug.cgi?id=170989
105         <rdar://problem/31705652>
106
107         Reviewed by Saam Barati.
108
109         * runtime/ArrayPrototype.cpp:
110         (JSC::arrayProtoFuncSlice):
111
112 2017-04-25  Don Olmstead  <don.olmstead@am.sony.com>
113
114         [Win] Use Clang's __has_declspec_attribute for export macros
115         https://bugs.webkit.org/show_bug.cgi?id=171240
116
117         Reviewed by Alex Christensen.
118
119         * runtime/JSExportMacros.h:
120
121 2017-04-25  Saam Barati  <sbarati@apple.com>
122
123         Unreviewed. Attempt armv7k build fix after r215720
124
125         I think we're just missing an include for the definition of ExecState::r().
126
127         * runtime/JSFixedArray.cpp:
128
129 2017-04-25  Daniel Bates  <dabates@apple.com>
130
131         [Cocoa][Win] Enable of X-Content-Type-Options: nosniff header
132         https://bugs.webkit.org/show_bug.cgi?id=136452
133         <rdar://problem/23412620>
134
135         Reviewed by Brent Fulgham.
136
137         Enable X-Content-Type-Options: nosniff on Mac, iOS and Windows platforms.
138
139         * Configurations/FeatureDefines.xcconfig:
140
141 2017-04-25  Mark Lam  <mark.lam@apple.com>
142
143         Local CSE wrongly CSEs array accesses with different result types.
144         https://bugs.webkit.org/show_bug.cgi?id=170990
145         <rdar://problem/31705945>
146
147         Reviewed by Saam Barati.
148
149         The fix is to use different LocationKind enums for the different type of array
150         result types.  This makes the HeapLocation values different based on the result
151         types, and allows CSE to discern between them.
152
153         * dfg/DFGCSEPhase.cpp:
154         * dfg/DFGClobberize.h:
155         (JSC::DFG::clobberize):
156         * dfg/DFGHeapLocation.cpp:
157         (WTF::printInternal):
158         * dfg/DFGHeapLocation.h:
159         (JSC::DFG::indexedPropertyLocForResultType):
160
161 2017-04-25  Mark Lam  <mark.lam@apple.com>
162
163         Make DFG SpeculatedType dumps easier to read.
164         https://bugs.webkit.org/show_bug.cgi?id=171280
165
166         Reviewed by Saam Barati.
167
168         Adding a pretty printer to insert |s between each type string and changing the
169         dumped strings to match the SpeculatedType names case-wise.
170
171         * bytecode/SpeculatedType.cpp:
172         (JSC::PrettyPrinter::PrettyPrinter):
173         (JSC::PrettyPrinter::print):
174         (JSC::dumpSpeculation):
175         * bytecode/SpeculatedType.h:
176
177 2017-04-25  JF Bastien  <jfbastien@apple.com>
178
179         lowerStackArgs: check Arg::addr.isValidForm when falling back to SP offsets
180         https://bugs.webkit.org/show_bug.cgi?id=171278
181
182         Reviewed by Filip Pizlo.
183
184         lowerStackArgs checked that the FP offsets it tries to generate
185         are valid form, but didn't check that the fallback was valid
186         form. This lead to stackAddr's assertion being dead, and the
187         MaroAssembler asserting way later on move / add when handed a huge
188         immediate.
189
190         * b3/air/AirArg.cpp:
191         (JSC::B3::Air::Arg::stackAddrImpl):
192
193 2017-04-25  Zan Dobersek  <zdobersek@igalia.com>
194
195         [aarch64] moveConditionally32(), moveConditionallyTest32() should move from/to 64-bit registers
196         https://bugs.webkit.org/show_bug.cgi?id=170891
197
198         Reviewed by Saam Barati.
199
200         moveConditionally32() and moveConditionallyTest32() operations in
201         MacroAssemblerARM64 properly perform comparisons and tests on 32-bit
202         values, but end up performing the moves from and to 32-bit registers.
203
204         Move operations should instead be done on 64-bit registers, just like
205         on the X86_64 platform. This is achieved by specifying 64 as the data
206         size for the csel instructions.
207
208         * assembler/MacroAssemblerARM64.h:
209         (JSC::MacroAssemblerARM64::moveConditionally32):
210         (JSC::MacroAssemblerARM64::moveConditionallyTest32):
211
212 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
213
214         test262: test262/test/language/expressions/object/method-definition/early-errors-object-method-duplicate-parameters.js
215         https://bugs.webkit.org/show_bug.cgi?id=171190
216
217         Reviewed by Saam Barati.
218
219         * bytecompiler/BytecodeGenerator.cpp:
220         (JSC::BytecodeGenerator::BytecodeGenerator):
221         (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
222         (JSC::BytecodeGenerator::emitNewFunction):
223         * bytecompiler/NodesCodegen.cpp:
224         (JSC::FunctionNode::emitBytecode):
225         (JSC::Scope::setSourceParseMode):
226         * parser/ParserModes.h:
227         (JSC::isFunctionParseMode):
228         (JSC::isMethodParseMode):
229         (JSC::isGeneratorOrAsyncFunctionWrapperParseMode):
230         (JSC::isGeneratorParseMode):
231         (JSC::isGeneratorWrapperParseMode):
232         * runtime/FunctionExecutable.h:
233         * runtime/JSFunction.cpp:
234         (JSC::JSFunction::getOwnPropertySlot):
235         Add a new GeneratorWrapperMethodMode parse mode. The other function types
236         (async, arrow) already have a FunctionMode and a MethodMode. Give
237         generators one as well. This lets isMethodParseMode actually be accurate.
238
239         * parser/Parser.cpp:
240         (JSC::Parser<LexerType>::parseInner):
241         (JSC::Parser<LexerType>::isArrowFunctionParameters):
242         (JSC::Parser<LexerType>::parseFormalParameters):
243         (JSC::stringForFunctionMode):
244         (JSC::Parser<LexerType>::parseFunctionParameters):
245         (JSC::Parser<LexerType>::parseFunctionInfo):
246         (JSC::Parser<LexerType>::parseClass):
247         (JSC::Parser<LexerType>::parsePropertyMethod):
248         * parser/Parser.h:
249         Add a duplicate parameter failure if there are duplicate parameters
250         in method syntax.
251
252 2017-04-24  Andy VanWagoner  <thetalecrafter@gmail.com>
253
254         Clean up ICU headers
255         https://bugs.webkit.org/show_bug.cgi?id=170997
256
257         Reviewed by JF Bastien.
258
259         Update all icu headers to 55.1
260
261         * icu/LICENSE: Update copyright
262         * icu/README: Explain ICU headers for OS X better
263         * icu/unicode/localpointer.h:
264         (LocalPointer::LocalPointer):
265         (LocalPointer::adoptInsteadAndCheckErrorCode):
266         * icu/unicode/platform.h:
267         * icu/unicode/putil.h:
268         * icu/unicode/ucal.h:
269         * icu/unicode/uchar.h:
270         * icu/unicode/ucnv.h:
271         * icu/unicode/ucol.h:
272         * icu/unicode/uconfig.h:
273         * icu/unicode/ucurr.h:
274         * icu/unicode/udatpg.h:
275         * icu/unicode/udisplaycontext.h:
276         * icu/unicode/uformattable.h:
277         * icu/unicode/uloc.h:
278         * icu/unicode/umachine.h:
279         * icu/unicode/unum.h:
280         * icu/unicode/unumsys.h:
281         * icu/unicode/urename.h:
282         * icu/unicode/uscript.h:
283         * icu/unicode/uset.h:
284         * icu/unicode/ustring.h:
285         * icu/unicode/utf8.h:
286         * icu/unicode/utypes.h:
287
288 2017-04-24  Yusuke Suzuki  <utatane.tea@gmail.com>
289
290         [JSC] Use JSFixedArray directly when using call_varargs
291         https://bugs.webkit.org/show_bug.cgi?id=171057
292
293         Reviewed by Saam Barati.
294
295         Previously we always emit new_array_with_spread when calling call(...args).
296         But this array is unnecessary if varargs operation can handle Spread directly.
297
298         This patch implements a peep-hole optimization in the bytecode compiler layer
299         to omit new_array_with_spread. This is very simple and effective because this
300         peep-hole optimization is quite common when using (...args) style calls and
301         this optimization works all the tiers. While we can implement the phase to
302         omit this NewArrayWithSpread in argument elimination phase, it only works
303         for FTL. While such an optimization can work with complex data flow, this
304         peep-hole optimization can optimize a common case easily.
305
306         For now, Spread and PhantomSpread can be directly drained by CallVarargs
307         and LoadVarargs related operations. We modify DFG and FTL to handle this correctly.
308
309         This shows six-speed improvement.
310
311             spread.es6                 89.4300+-2.0236     ^     69.6015+-1.7278        ^ definitely 1.2849x faster
312             spread-generator.es6      344.7879+-5.9147     ^    331.2712+-6.8610        ^ definitely 1.0408x faster
313
314         * bytecompiler/BytecodeGenerator.cpp:
315         (JSC::BytecodeGenerator::emitCall):
316         (JSC::BytecodeGenerator::emitConstruct):
317         * dfg/DFGArgumentsEliminationPhase.cpp:
318         * dfg/DFGPreciseLocalClobberize.h:
319         (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
320         * ftl/FTLLowerDFGToB3.cpp:
321         (JSC::FTL::DFG::LowerDFGToB3::compileSpread):
322         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
323         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
324         (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
325         (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargsWithSpread):
326         * interpreter/Interpreter.cpp:
327         (JSC::sizeOfVarargs):
328         (JSC::loadVarargs):
329         * parser/Nodes.h:
330         (JSC::ArrayNode::elements):
331         * runtime/JSFixedArray.cpp:
332         (JSC::JSFixedArray::copyToArguments):
333         * runtime/JSFixedArray.h:
334
335 2017-04-24  Yusuke Suzuki  <utatane.tea@gmail.com>
336
337         [WTF] Move JSC tools/StackTrace to WTF and unify stack trace dump code
338         https://bugs.webkit.org/show_bug.cgi?id=171199
339
340         Reviewed by Mark Lam.
341
342         This patch adds a utility method to produce demangled names with dladdr.
343         It fixes several memory leaks because the result of abi::__cxa_demangle()
344         needs to be `free`-ed.
345
346         * CMakeLists.txt:
347         * JavaScriptCore.xcodeproj/project.pbxproj:
348         * inspector/JSGlobalObjectInspectorController.cpp:
349         (Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace):
350         * runtime/SamplingProfiler.cpp:
351         (JSC::SamplingProfiler::StackFrame::displayName):
352         * tools/CellProfile.h:
353         * tools/CodeProfile.cpp:
354         (JSC::CodeProfile::report):
355         (JSC::symbolName): Deleted.
356
357 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
358
359         Web Inspector: ObjC RWIProtocol codegen should better handle optional members
360         https://bugs.webkit.org/show_bug.cgi?id=171251
361         <rdar://problem/31697002>
362
363         Reviewed by Brian Burg.
364
365         * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
366         (ObjCProtocolTypesImplementationGenerator._generate_getter_for_member):
367         * inspector/scripts/codegen/objc_generator.py:
368         (ObjCGenerator.protocol_to_objc_expression_for_member):
369         (ObjCGenerator.protocol_to_objc_code_block_for_object_member):
370         Always be safe and nil check object property accesses, optional or not.
371
372         * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
373         * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
374         Rebaselined inspector generator tests.
375
376 2017-04-24  Saam Barati  <sbarati@apple.com>
377
378         ASSERTION FAILED: m_table seen with workers/wasm-hashset LayoutTests
379         https://bugs.webkit.org/show_bug.cgi?id=171119
380         <rdar://problem/31760635>
381
382         Reviewed by Keith Miller.
383
384         The HashSet of timer set notification callbacks can be accessed
385         and augmented simultaneously from different threads. e.g, the worker
386         thread can augment it while the wasm compilation thread will
387         access it. Therefore, accesses must be guarded by a lock.
388
389         * runtime/JSRunLoopTimer.cpp:
390         (JSC::JSRunLoopTimer::scheduleTimer):
391         (JSC::JSRunLoopTimer::addTimerSetNotification):
392         (JSC::JSRunLoopTimer::removeTimerSetNotification):
393         * runtime/JSRunLoopTimer.h:
394
395 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
396
397         test262: test262/test/language/computed-property-names/class/static/getter-prototype.js
398         https://bugs.webkit.org/show_bug.cgi?id=170897
399
400         Reviewed by Saam Barati.
401
402         * parser/ASTBuilder.h:
403         (JSC::ASTBuilder::createArguments):
404         (JSC::ASTBuilder::createArgumentsList):
405         Reorder so all the createProperty methods are grouped together.
406
407         * parser/Parser.h:
408         * parser/Parser.cpp:
409         (JSC::Parser<LexerType>::parseClass):
410         (JSC::Parser<LexerType>::parseProperty):
411         (JSC::Parser<LexerType>::parseGetterSetter):
412         Refine the conditions for syntax errors for getter/setter
413         properties names. "prototype" is not allowed as a static
414         and "constructor" is not all when non-static.
415
416         * runtime/JSObject.cpp:
417         (JSC::JSObject::putGetter):
418         (JSC::JSObject::putSetter):
419         Throw exceptions. These methods are only used by this path
420         via op_put_getter_by_val / op_put_setter_by_val.
421
422 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
423
424         test262: test262/test/language/statements/for-of/dstr-array-elem-init-fn-name-arrow.js
425         https://bugs.webkit.org/show_bug.cgi?id=171160
426
427         Reviewed by JF Bastien.
428
429         * parser/ASTBuilder.h:
430         (JSC::ASTBuilder::tryInferNameInPattern):
431         (JSC::ASTBuilder::tryInferNameInPatternWithIdentifier):
432         We supported getting the name from a BindingNode.
433         We extend this to support getting the name from a
434         ResolveNode inside of an AssignmentElementNode.
435
436         * parser/Nodes.h:
437         (JSC::DestructuringPatternNode::isAssignmentElementNode):
438         (JSC::AssignmentElementNode::isAssignmentElementNode):
439         Make it possible to identify an assignment element node.
440
441 2017-04-24  Alex Christensen  <achristensen@webkit.org>
442
443         Reduce copies and allocations in SharedBuffer::append
444         https://bugs.webkit.org/show_bug.cgi?id=170956
445
446         Reviewed by Andreas Kling.
447
448         * runtime/ArrayBuffer.h:
449
450 2017-04-24  Carlos Garcia Campos  <cgarcia@igalia.com>
451
452         [GTK] Switch to use ENABLE_REMOTE_INSPECTOR instead of ENABLE_INSPECTOR_SERVER for the remote inspector
453         https://bugs.webkit.org/show_bug.cgi?id=166680
454
455         Reviewed by Michael Catanzaro.
456
457         Add GTK+ port implementation of RemoteInspector.
458
459         * PlatformGTK.cmake:
460         * inspector/remote/RemoteConnectionToTarget.h:
461         * inspector/remote/RemoteInspector.h:
462         * inspector/remote/glib/RemoteConnectionToTargetGlib.cpp: Added.
463         (Inspector::RemoteConnectionToTarget::RemoteConnectionToTarget):
464         (Inspector::RemoteConnectionToTarget::~RemoteConnectionToTarget):
465         (Inspector::RemoteConnectionToTarget::setup):
466         (Inspector::RemoteConnectionToTarget::sendMessageToTarget):
467         (Inspector::RemoteConnectionToTarget::close):
468         (Inspector::RemoteConnectionToTarget::targetClosed):
469         (Inspector::RemoteConnectionToTarget::targetIdentifier):
470         (Inspector::RemoteConnectionToTarget::sendMessageToFrontend):
471         * inspector/remote/glib/RemoteInspectorGlib.cpp: Added.
472         (Inspector::RemoteInspector::singleton):
473         (Inspector::RemoteInspector::RemoteInspector):
474         (Inspector::RemoteInspector::start):
475         (Inspector::RemoteInspector::stopInternal):
476         (Inspector::RemoteInspector::setupConnection):
477         (Inspector::dbusConnectionCallAsyncReadyCallback):
478         (Inspector::RemoteInspector::listingForInspectionTarget):
479         (Inspector::RemoteInspector::listingForAutomationTarget):
480         (Inspector::RemoteInspector::pushListingsNow):
481         (Inspector::RemoteInspector::pushListingsSoon):
482         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
483         (Inspector::RemoteInspector::sendAutomaticInspectionCandidateMessage):
484         (Inspector::RemoteInspector::sendMessageToRemote):
485         (Inspector::RemoteInspector::receivedGetTargetListMessage):
486         (Inspector::RemoteInspector::receivedSetupMessage):
487         (Inspector::RemoteInspector::receivedDataMessage):
488         (Inspector::RemoteInspector::receivedCloseMessage):
489         (Inspector::RemoteInspector::setup):
490         (Inspector::RemoteInspector::sendMessageToTarget):
491         (Inspector::RemoteInspector::requestAutomationSession):
492         * inspector/remote/glib/RemoteInspectorServer.cpp: Added.
493         (Inspector::generateConnectionID):
494         (Inspector::RemoteInspectorServer::singleton):
495         (Inspector::RemoteInspectorServer::~RemoteInspectorServer):
496         (Inspector::RemoteInspectorServer::interfaceInfo):
497         (Inspector::RemoteInspectorServer::start):
498         (Inspector::RemoteInspectorServer::newConnectionCallback):
499         (Inspector::RemoteInspectorServer::connectionClosedCallback):
500         (Inspector::RemoteInspectorServer::newConnection):
501         (Inspector::dbusConnectionCallAsyncReadyCallback):
502         (Inspector::RemoteInspectorServer::setTargetList):
503         (Inspector::RemoteInspectorServer::clientConnectionClosedCallback):
504         (Inspector::RemoteInspectorServer::getTargetList):
505         (Inspector::RemoteInspectorServer::setup):
506         (Inspector::RemoteInspectorServer::close):
507         (Inspector::RemoteInspectorServer::clientConnectionClosed):
508         (Inspector::RemoteInspectorServer::connectionClosed):
509         (Inspector::RemoteInspectorServer::sendMessageToBackend):
510         (Inspector::RemoteInspectorServer::sendMessageToFrontend):
511         (Inspector::RemoteInspectorServer::startAutomationSession):
512         * inspector/remote/glib/RemoteInspectorServer.h: Added.
513         (Inspector::RemoteInspectorServer::isRunning):
514
515 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
516
517         test262: test262/test/language/expressions/generators/yield-as-label.js
518         https://bugs.webkit.org/show_bug.cgi?id=170979
519
520         Reviewed by Saam Barati.
521
522         * parser/Parser.cpp:
523         (JSC::Parser<LexerType>::parseVariableDeclarationList):
524         (JSC::Parser<LexerType>::parseDestructuringPattern):
525         (JSC::Parser<LexerType>::parseFormalParameters):
526         Converge on "Cannot" instead of "Can't" in error messages.
527
528         (JSC::Parser<LexerType>::parseFunctionInfo):
529         Disallow "yield" as the generator function name in function expressions.
530         This refers to the difference between Declaration and Expression, where
531         only GeneratorExpression explicitly has [+Yield] disallowing yield for
532         the generator name:
533
534             GeneratorDeclaration[Yield, Await, Default]:
535                 function * BindingIdentifier[?Yield, ?Await] ...
536
537             GeneratorExpression:
538                 function * BindingIdentifier[+Yield, ~Await]opt ...
539
540         (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
541         Disallow "yield" as a label name in strict mode or inside a generator.
542
543         (JSC::Parser<LexerType>::parseProperty):
544         Disallow "yield" or any keyword in object literal shorthands.
545
546         * parser/Parser.h:
547         (JSC::Parser::getToken):
548         (JSC::Parser::isDisallowedIdentifierLet):
549         (JSC::Parser::isDisallowedIdentifierYield):
550         (JSC::Parser::disallowedIdentifierLetReason):
551         (JSC::Parser::disallowedIdentifierYieldReason):
552         Follow pattern for improved error messages based on context.
553
554 2017-04-23  Commit Queue  <commit-queue@webkit.org>
555
556         Unreviewed, rolling out r215674.
557         https://bugs.webkit.org/show_bug.cgi?id=171212
558
559         Possible unintended commit. This patch was on the wrong bug.
560         (Requested by JoePeck on #webkit).
561
562         Reverted changeset:
563
564         "test262: test262/test/language/expressions/generators/yield-
565         as-label.js"
566         https://bugs.webkit.org/show_bug.cgi?id=170979
567         http://trac.webkit.org/changeset/215674
568
569 2017-04-23  Joseph Pecoraro  <pecoraro@apple.com>
570
571         test262: test262/test/built-ins/Number/prototype/toPrecision/nan.js
572         https://bugs.webkit.org/show_bug.cgi?id=171197
573
574         Reviewed by Saam Barati.
575
576         * runtime/NumberPrototype.cpp:
577         (JSC::numberProtoFuncToExponential):
578         (JSC::numberProtoFuncToFixed):
579         (JSC::numberProtoFuncToPrecision):
580         Refine the order of operations to match the spec.
581
582 2017-04-23  Joseph Pecoraro  <pecoraro@apple.com>
583
584         test262: test262/test/language/expressions/generators/yield-as-label.js
585         https://bugs.webkit.org/show_bug.cgi?id=170979
586
587         Reviewed by Saam Barati.
588
589         * parser/Parser.cpp:
590         (JSC::Parser<LexerType>::parseVariableDeclarationList):
591         (JSC::Parser<LexerType>::parseDestructuringPattern):
592         (JSC::Parser<LexerType>::parseFormalParameters):
593         Converge on "Cannot" instead of "Can't" in error messages.
594
595         (JSC::Parser<LexerType>::parseFunctionInfo):
596         Disallow "yield" as the generator function name in function expressions.
597         This refers to the difference between Declaration and Expression, where
598         only GeneratorExpression explicitly has [+Yield] disallowing yield for
599         the generator name:
600
601             GeneratorDeclaration[Yield, Await, Default]:
602                 function * BindingIdentifier[?Yield, ?Await] ...
603
604             GeneratorExpression:
605                 function * BindingIdentifier[+Yield, ~Await]opt ...
606
607         (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
608         Disallow "yield" as a label name in strict mode or inside a generator.
609
610         (JSC::Parser<LexerType>::parseProperty):
611         Disallow "yield" or any keyword in object literal shorthands.
612
613         * parser/Parser.h:
614         (JSC::Parser::getToken):
615         (JSC::Parser::isDisallowedIdentifierLet):
616         (JSC::Parser::isDisallowedIdentifierYield):
617         (JSC::Parser::disallowedIdentifierLetReason):
618         (JSC::Parser::disallowedIdentifierYieldReason):
619         Follow pattern for improved error messages based on context.
620
621 2017-04-23  Joseph Pecoraro  <pecoraro@apple.com>
622
623         test262: test262/test/built-ins/Number/parseFloat.js
624         https://bugs.webkit.org/show_bug.cgi?id=171193
625
626         Reviewed by Yusuke Suzuki.
627
628         * runtime/CommonIdentifiers.h:
629         * runtime/JSGlobalObject.cpp:
630         (JSC::JSGlobalObject::init):
631         (JSC::JSGlobalObject::visitChildren):
632         * runtime/JSGlobalObject.h:
633         (JSC::JSGlobalObject::parseFloatFunction):
634         Expose parseFloat on the global object to be shared with Number constructor.
635
636         * runtime/NumberConstructor.cpp:
637         (JSC::NumberConstructor::finishCreation):
638         parseFloat uses the same value as the global parseFloat.
639
640 2017-04-22  Yusuke Suzuki  <utatane.tea@gmail.com>
641
642         [JSC] Use DoublyLinkedList for MachineThread
643         https://bugs.webkit.org/show_bug.cgi?id=171171
644
645         Reviewed by Mark Lam.
646
647         MachineThread can use WTF::DoublyLinkedList to simplify
648         its implementation. We should not use Vector<> etc. since
649         we do not want to call allocations during suspending and
650         resuming threads.
651
652         * heap/MachineStackMarker.cpp:
653         (JSC::MachineThreads::MachineThreads):
654         (JSC::MachineThreads::~MachineThreads):
655         (JSC::MachineThreads::addCurrentThread):
656         (JSC::MachineThreads::removeThreadIfFound):
657         (JSC::MachineThreads::MachineThread::MachineThread):
658         (JSC::MachineThreads::tryCopyOtherThreadStacks):
659         * heap/MachineStackMarker.h:
660         (JSC::MachineThreads::threadsListHead):
661         * runtime/SamplingProfiler.cpp:
662         (JSC::FrameWalker::isValidFramePointer):
663         * runtime/VMTraps.cpp:
664         (JSC::findActiveVMAndStackBounds):
665
666 2017-04-22  JF Bastien  <jfbastien@apple.com>
667
668         WebAssembly: Module.exports, Module.imports, Module.customSections are wrong
669         https://bugs.webkit.org/show_bug.cgi?id=171078
670
671         Reviewed by Saam Barati.
672
673         They're static properties of Module, not instance properties of a module.
674         https://github.com/WebAssembly/design/blob/master/JS.md#webassemblymoduleexports
675
676         * wasm/js/WebAssemblyModuleConstructor.cpp:
677         (JSC::webAssemblyModuleCustomSections):
678         (JSC::webAssemblyModuleImports):
679         (JSC::webAssemblyModuleExports):
680         * wasm/js/WebAssemblyModulePrototype.cpp:
681         (JSC::webAssemblyModuleProtoCustomSections): Deleted.
682         (JSC::webAssemblyModuleProtoImports): Deleted.
683         (JSC::webAssemblyModuleProtoExports): Deleted.
684
685 2017-04-21  Saam Barati  <sbarati@apple.com>
686
687         SharedArrayBuffer-opt.js fails with Briggs
688         https://bugs.webkit.org/show_bug.cgi?id=170948
689         <rdar://problem/31740568>
690
691         Reviewed by Michael Saboff.
692
693         The bug was not actually with Briggs, but instead was with
694         our X86-64 MacroAssembler. Michael fixed the bug here:
695         https://trac.webkit.org/changeset/215618/webkit
696         
697         The issue was we weren't adding the REX byte for AtomicXchg8,
698         leading to the incorrect encoding for the result register depending
699         on which register it was. If you look at this code, you'll see the issue:
700
701           Int32 @38 = AtomicXchg(@59, @64, width = 8, range = 0, fenceRange = 0, ControlDependent|Fence|Writes:0|Reads:0, DFG:@49)
702               AtomicXchg8 %rsi, (%rax,%rdx), @38
703                   0x2dcb5bc0015e: lock xchg %dh, (%rax,%rdx)
704           Int32 @66 = Const32(255, DFG:@49)
705           Int32 @67 = BitAnd(@38, $255(@66), DFG:@49)
706               ZeroExtend8To32 %rsi, %rax, @67
707                   0x2dcb5bc00162: movzx %sil, %eax
708
709         Air thought the result was in the lower 8 bits of %rsi,
710         however, the code we emitted stored it in the [8-15] bits
711         of %rdx. Since this issue is fixed, I'm turning Briggs back
712         on.
713
714         * b3/air/AirAllocateRegistersByGraphColoring.h:
715         (JSC::B3::Air::useIRC):
716
717 2017-04-20  Mark Lam  <mark.lam@apple.com>
718
719         Refactor MASM probe to allow printing of custom types.
720         https://bugs.webkit.org/show_bug.cgi?id=171101
721
722         Reviewed by JF Bastien.
723
724         For example, this allows us to add MASM printing of CodeBlock* and Air::Args.
725
726         In general, MASM print can be used like dataLog, except that it generates JITted
727         code for doing the dataLogging later when the JITted code runs.  MASM print can
728         print any value type that a specialized Printer template or a setPrinter()
729         function implemented for that type.
730
731         * CMakeLists.txt:
732         * JavaScriptCore.xcodeproj/project.pbxproj:
733         * assembler/MacroAssembler.h:
734
735         * assembler/MacroAssemblerPrinter.cpp:
736         (JSC::Printer::printAllRegisters):
737         (JSC::Printer::printPCRegister):
738         (JSC::Printer::printRegisterID):
739         (JSC::Printer::printFPRegisterID):
740         (JSC::Printer::printAddress):
741         (JSC::Printer::printMemory):
742         (JSC::Printer::printCallback):
743         (JSC::printIndent): Deleted.
744         (JSC::printCPU): Deleted.
745         (JSC::printCPURegisters): Deleted.
746         (JSC::printPC): Deleted.
747         (JSC::printRegister): Deleted.
748         (JSC::printMemory): Deleted.
749         (JSC::MacroAssemblerPrinter::printCallback): Deleted.
750         * assembler/MacroAssemblerPrinter.h:
751         (JSC::AllRegisters::AllRegisters):
752         (JSC::Printer::Printer<AllRegisters>::Printer):
753         (JSC::Printer::Printer<PCRegister>::Printer):
754         (JSC::Printer::Printer<MacroAssembler::RegisterID>::Printer):
755         (JSC::Printer::Printer<MacroAssembler::FPRegisterID>::Printer):
756         (JSC::Printer::Printer<MacroAssembler::Address>::Printer):
757         (JSC::Printer::Printer<Memory>::Printer):
758         (JSC::Printer::Printer<MemWord<IntType>>::Printer):
759         (JSC::MacroAssembler::print):
760         (JSC::MacroAssemblerPrinter::print): Deleted.
761         (JSC::MacroAssemblerPrinter::PrintArg::PrintArg): Deleted.
762         (JSC::MacroAssemblerPrinter::appendPrintArg): Deleted.
763         - Refactored to move the underlying PrintRecord (and associated data structures)
764           out to Printer.cpp/h.
765         - MacroAssemblerPrinter.cpp/h now only add custom Printers for MASM types like
766           RegisterID and Memory.  It also defines the implementation of
767           MacroAssembler::print().
768
769           As before, JIT code that wishes to use MacroAssembler::print() needs to
770           #include "MacroAssemblerPrinter.h".
771
772         - Also added the ability to specify an optional indentation (in number of chars)
773           when MASM printing AllRegisters.  This is useful because AllRegisters prints
774           a block of data unlike other printers which print inline.
775
776         * assembler/Printer.cpp: Added.
777         (JSC::Printer::printConstCharString):
778         (JSC::Printer::printIntptr):
779         (JSC::Printer::printUintptr):
780         (JSC::Printer::printPointer):
781         (JSC::Printer::setPrinter):
782         * assembler/Printer.h: Added.
783         (JSC::Printer::Context::Context):
784         (JSC::Printer::PrintRecord::PrintRecord):
785         (JSC::Printer::appendPrinter):
786         (JSC::Printer::makePrintRecordList):
787         (JSC::Printer::Printer<RawPointer>::Printer):
788         (JSC::Printer::setPrinter):
789         (JSC::Printer::Printer::Printer):
790         - Data structures for creating a list of PrintRecords.  Classes which wish to
791           add custom support for MASM printing can #include "Printer.h" and implement
792           either:
793           1. a specialized Printer template, or
794           2. a setPrinter() function.
795
796           See Printer<Reg> and Printer<B3::Air::Tmp> in AirPrintSpecial.h for examples of
797           (1).  See CodeBlock's setPrinter() for an example of (2).
798
799         * b3/B3LowerToAir.cpp:
800         (JSC::B3::Air::LowerToAir::print):
801         * b3/air/AirPrintSpecial.cpp: Added.
802         (JSC::B3::Air::PrintSpecial::PrintSpecial):
803         (JSC::B3::Air::PrintSpecial::~PrintSpecial):
804         (JSC::B3::Air::PrintSpecial::forEachArg):
805         (JSC::B3::Air::PrintSpecial::isValid):
806         (JSC::B3::Air::PrintSpecial::admitsStack):
807         (JSC::B3::Air::PrintSpecial::reportUsedRegisters):
808         (JSC::B3::Air::PrintSpecial::generate):
809         (JSC::B3::Air::PrintSpecial::extraEarlyClobberedRegs):
810         (JSC::B3::Air::PrintSpecial::extraClobberedRegs):
811         (JSC::B3::Air::PrintSpecial::dumpImpl):
812         (JSC::B3::Air::PrintSpecial::deepDumpImpl):
813         (JSC::Printer::printAirArg):
814         * b3/air/AirPrintSpecial.h: Added.
815         (JSC::Printer::appendAirArg):
816         (JSC::Printer::appendAirArgs):
817         (JSC::Printer::Printer<B3::Air::Tmp>::Printer):
818         (JSC::Printer::Printer<Reg>::Printer):
819         - Add the print() operation for use in LowerToAir.  print() will emit a
820           PrintSpecial that will ultimately emit a MASM print to print what we want.
821         - LowerToAir's print() adds the ability to print Air::Args.
822         - Unlike in the baseline JIT and the DFG, LowerToAir's print() can perturb the
823           usage of registers.  This is because PrintSpecial is a patch point, and it
824           prevents certain optimizations.  If not used carefully, an attempt to print()
825           an Arg by taking a Tmp, can force the B3 Value into a Tmp earlier than it would
826           otherwise do so.  So, use LowerToAir's print() with care.
827
828         * bytecode/CodeBlock.cpp:
829         (JSC::setPrinter):
830         - Now we can MASM print CodeBlock*.
831         (WTF::printInternal):
832         - Now we can dataLog CodeBlock* (including null CodeBlock pointers).
833
834         * bytecode/CodeBlock.h:
835
836         * runtime/VM.cpp:
837         (JSC::VM::throwException):
838         - Use the new ability to dataLog CodeBlock*.  No need to do an explicit null
839           check before printing anymore.
840
841 2017-04-21  Keith Miller  <keith_miller@apple.com>
842
843         Unreviewed, rolling out r215634.
844
845         underlying build issues should have been fixed
846
847         Reverted changeset:
848
849         "Unreviewed, rolling out r215620 and r215623."
850         https://bugs.webkit.org/show_bug.cgi?id=171139
851         http://trac.webkit.org/changeset/215634
852
853 2017-04-21  Commit Queue  <commit-queue@webkit.org>
854
855         Unreviewed, rolling out r215620 and r215623.
856         https://bugs.webkit.org/show_bug.cgi?id=171139
857
858         broke arm64 build (Requested by keith_miller on #webkit).
859
860         Reverted changesets:
861
862         "Add signaling API"
863         https://bugs.webkit.org/show_bug.cgi?id=170976
864         http://trac.webkit.org/changeset/215620
865
866         "Unreviewed, fix Cloop build."
867         http://trac.webkit.org/changeset/215623
868
869 2017-04-21  Keith Miller  <keith_miller@apple.com>
870
871         Remove LL/SC from Atomics
872         https://bugs.webkit.org/show_bug.cgi?id=171141
873
874         Reviewed by Saam Barati.
875
876         Adding load link and store conditionally was not an actual progression
877         and the existing code is causing problems for users of Atomics. So let's
878         get rid of it.
879
880         * heap/LargeAllocation.h:
881         (JSC::LargeAllocation::testAndSetMarked):
882         * heap/MarkedBlock.h:
883         (JSC::MarkedBlock::testAndSetMarked):
884         * heap/SlotVisitor.cpp:
885         (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
886
887 2017-04-21  Keith Miller  <keith_miller@apple.com>
888
889         Unreviewed, fix Cloop build.
890
891         * jit/ExecutableAllocator.h:
892         (JSC::isJITPC):
893
894 2017-04-20  Keith Miller  <keith_miller@apple.com>
895
896         Add signaling API
897         https://bugs.webkit.org/show_bug.cgi?id=170976
898
899         Reviewed by Filip Pizlo.
900
901         Update various uses of sigaction to use the new signaling API.
902         Also switch VMTraps to use the thread message system instead of
903         rolling it's own.
904
905         * jit/ExecutableAllocator.h:
906         (JSC::isJITPC):
907         * runtime/VMTraps.cpp:
908         (JSC::installSignalHandler):
909         (JSC::VMTraps::VMTraps):
910         (JSC::VMTraps::SignalSender::send):
911         (JSC::handleSigusr1): Deleted.
912         (JSC::handleSigtrap): Deleted.
913         (JSC::installSignalHandlers): Deleted.
914         * runtime/VMTraps.h:
915         * tools/SigillCrashAnalyzer.cpp:
916         (JSC::installCrashHandler):
917         (JSC::handleCrash): Deleted.
918         * wasm/WasmFaultSignalHandler.cpp:
919         (JSC::Wasm::trapHandler):
920         (JSC::Wasm::enableFastMemory):
921
922 2017-04-21  Michael Saboff  <msaboff@apple.com>
923
924         X86-64 Assembler doesn't handle xchg with byte register src
925         https://bugs.webkit.org/show_bug.cgi?id=171118
926
927         Reviewed by Saam Barati.
928
929         * assembler/X86Assembler.h:
930         (JSC::X86Assembler::xchgb_rm): Use oneByteOp8() since these are 8 bit opcodes.
931
932 2017-04-21  Andy VanWagoner  <thetalecrafter@gmail.com>
933
934         [INTL] Implement Intl.DateTimeFormat.prototype.formatToParts
935         https://bugs.webkit.org/show_bug.cgi?id=169458
936
937         Reviewed by JF Bastien.
938
939         Use udat_formatForFields to iterate through the parts of a formatted date string.
940         Make formatToParts and related functions dependent on ICU version >= 55.
941
942         * icu/unicode/udat.h: Update to 55.1.
943         * icu/unicode/ufieldpositer.h: Added from 55.1.
944         * icu/unicode/uvernum.h: Update to 55.1
945         * runtime/IntlDateTimeFormat.cpp:
946         (JSC::IntlDateTimeFormat::partTypeString): Convert UDateFormatField to string.
947         (JSC::IntlDateTimeFormat::formatToParts): Return parts of formatted date string.
948         * runtime/IntlDateTimeFormat.h:
949         * runtime/IntlDateTimeFormatPrototype.cpp:
950         (JSC::IntlDateTimeFormatPrototypeFuncFormatToParts): Add prototype function formatToParts.
951
952 2017-04-20  Konstantin Tokarev  <annulen@yandex.ru>
953
954         [cmake] Define FORWARDING_HEADERS_DIR in WebKitFS and use it everywhere
955         https://bugs.webkit.org/show_bug.cgi?id=171071
956
957         Reviewed by Michael Catanzaro.
958
959         "${DERIVED_SOURCES_DIR}/ForwardingHeaders" path occurs very often in the
960         build system files. GTK-specifc FORWARDING_HEADERS_DIR variable should
961         be available for all ports.
962
963         * CMakeLists.txt:
964         * PlatformWin.cmake:
965
966 2017-04-20  Konstantin Tokarev  <annulen@yandex.ru>
967
968         Remove unused lamda captures
969         https://bugs.webkit.org/show_bug.cgi?id=171098
970
971         Reviewed by Yusuke Suzuki.
972
973         * bytecompiler/NodesCodegen.cpp:
974         (JSC::ArrayNode::emitBytecode):
975         * ftl/FTLState.cpp:
976         (JSC::FTL::State::State):
977         * wasm/WasmB3IRGenerator.cpp:
978
979 2017-04-20  Yusuke Suzuki  <utatane.tea@gmail.com>
980
981         [JSC][FTL] FTL should support Arrayify
982         https://bugs.webkit.org/show_bug.cgi?id=169596
983
984         Reviewed by Saam Barati.
985
986         This patch simply expands the coverage of FTL by supporting Arrayify.
987         While ArrayifyToStructure is already supported, Arrayify is not supported
988         in FTL. While supporting Arrayify in FTL itself does not offer so much
989         performance difference from DFG's one, no FTL support for Arrayify
990         prevents us applying FTL to the code including Arrayify.
991
992         * dfg/DFGArrayMode.cpp:
993         (JSC::DFG::toIndexingShape):
994         * dfg/DFGSpeculativeJIT.cpp:
995         (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode):
996         * ftl/FTLCapabilities.cpp:
997         (JSC::FTL::canCompile):
998         * ftl/FTLLowerDFGToB3.cpp:
999         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1000         (JSC::FTL::DFG::LowerDFGToB3::compileArrayify):
1001         (JSC::FTL::DFG::LowerDFGToB3::compileCheckArray):
1002         (JSC::FTL::DFG::LowerDFGToB3::isArrayTypeForArrayify):
1003         (JSC::FTL::DFG::LowerDFGToB3::isArrayTypeForCheckArray):
1004         (JSC::FTL::DFG::LowerDFGToB3::compileArrayifyToStructure): Deleted.
1005         (JSC::FTL::DFG::LowerDFGToB3::isArrayType): Deleted.
1006
1007 2017-04-20  Mark Lam  <mark.lam@apple.com>
1008
1009         virtualThunkFor() needs to materialize its of tagMaskRegister for tail calls.
1010         https://bugs.webkit.org/show_bug.cgi?id=171079
1011         <rdar://problem/31684756>
1012
1013         Reviewed by Saam Barati.
1014
1015         This is needed because tail calls would restore callee saved registers (and
1016         therefore, potentially clobber the tag registers) before jumping to the thunk.
1017
1018         * jit/ThunkGenerators.cpp:
1019         (JSC::virtualThunkFor):
1020
1021 2017-04-20  Mark Lam  <mark.lam@apple.com>
1022
1023         Build fix after r215592.
1024         https://bugs.webkit.org/show_bug.cgi?id=171088
1025
1026         Not reviewed.
1027
1028         * assembler/MacroAssemblerPrinter.h:
1029
1030 2017-04-20  Mark Lam  <mark.lam@apple.com>
1031
1032         Update the MASM probe to only take 1 arg instead of 2 (in addition to the callback function).
1033         https://bugs.webkit.org/show_bug.cgi?id=171088
1034
1035         Reviewed by Michael Saboff and Saam Barati.
1036
1037         Experience shows that we never use the 2nd arg.  So, let's remove it to reduce
1038         the footprint at each probe site.
1039
1040         Also fix the MacroAssembler::print() function so that it is a no-op when
1041         !ENABLE(MASM_PROBE).  This will allow us to have print() statements in JIT code
1042         without a lot of #if ENABLE(MASM_PROBE)s later.
1043
1044         * assembler/AbstractMacroAssembler.h:
1045         * assembler/MacroAssembler.cpp:
1046         (JSC::stdFunctionCallback):
1047         (JSC::MacroAssembler::probe):
1048         * assembler/MacroAssembler.h:
1049         * assembler/MacroAssemblerARM.cpp:
1050         (JSC::MacroAssemblerARM::probe):
1051         * assembler/MacroAssemblerARM.h:
1052         * assembler/MacroAssemblerARM64.cpp:
1053         (JSC::MacroAssemblerARM64::probe):
1054         * assembler/MacroAssemblerARM64.h:
1055         * assembler/MacroAssemblerARMv7.cpp:
1056         (JSC::MacroAssemblerARMv7::probe):
1057         * assembler/MacroAssemblerARMv7.h:
1058         * assembler/MacroAssemblerPrinter.cpp:
1059         (JSC::MacroAssemblerPrinter::printCallback):
1060         * assembler/MacroAssemblerPrinter.h:
1061         (JSC::MacroAssemblerPrinter::print):
1062         (JSC::MacroAssembler::print):
1063         * assembler/MacroAssemblerX86Common.cpp:
1064         (JSC::MacroAssemblerX86Common::probe):
1065         * assembler/MacroAssemblerX86Common.h:
1066
1067 2017-04-20  Matt Baker  <mattbaker@apple.com>
1068
1069         Web Inspector: Add regular expression support to XHR breakpoints
1070         https://bugs.webkit.org/show_bug.cgi?id=170099
1071         <rdar://problem/31558082>
1072
1073         Reviewed by Joseph Pecoraro.
1074
1075         * inspector/protocol/DOMDebugger.json:
1076         New optional `isRegex` parameter denotes whether `url` contains
1077         a regular expression.
1078
1079 2017-04-15  Filip Pizlo  <fpizlo@apple.com>
1080
1081         Optimize SharedArrayBuffer in the DFG+FTL
1082         https://bugs.webkit.org/show_bug.cgi?id=164108
1083
1084         Reviewed by Saam Barati.
1085         
1086         This adds atomics intrinsics to the DFG and wires them through to the DFG and FTL backends. This
1087         was super easy in the FTL since B3 already has comprehensive atomic intrinsics, which are more
1088         powerful than what we need right now. In the DFG backend, I went with an easy-to-write
1089         implementation that just reduces everything to a weak CAS loop. It's very inefficient with
1090         registers (it needs ~8) but it's the DFG backend, so it's not obvious how much we care.
1091         
1092         To make the rare cases easy to handle, I refactored AtomicsObject.cpp so that the operations for
1093         the slow paths can share code with the native functions.
1094         
1095         This also fixes register handling in the X86 implementations of CAS, in the case that
1096         expectedAndResult is not %rax. This also fixes the ARM64 implementation of branchWeakCAS.
1097         
1098         I adapted the CascadeLock from WTF/benchmarks/ToyLocks.h as a microbenchmark of lock performance.
1099         This benchmark performs 2.5x faster, in both the contended and uncontended case, thanks to this
1100         change. It's still about 3x slower than native. I investigated this only a bit. I suspect that
1101         the story will be different in asm.js code, which will get constant-folding of the typed array
1102         backing store by virtue of how it uses lexically scoped variables as pointers to the heap arrays.
1103         It's worth noting that the native lock I was comparing against, the very nicely-tuned
1104         CascadeLock, is at the very high end of lock throughput under virtually all conditions
1105         (uncontended, microcontended, held for a long time). I also compared to WTF::Lock and others, and
1106         the only ones that performed better in this microbenchmark were spinlocks. I don't recommend
1107         using those. So, when I say this is 3x slower than native, I really mean that it's 3x slower than
1108         the fastest native lock that I have in my arsenal.
1109         
1110         Also worth noting is that I experimented with exposing Atomics.yield(), which uses sched_yield,
1111         as a way of testing if adding a yield loop to the JS cascadeLock would help. It does not help. I
1112         did not investigate why.
1113
1114         * assembler/AbstractMacroAssembler.h:
1115         (JSC::AbstractMacroAssembler::JumpList::append):
1116         * assembler/CPU.h:
1117         (JSC::is64Bit):
1118         (JSC::is32Bit):
1119         * b3/B3Common.h:
1120         (JSC::B3::is64Bit): Deleted.
1121         (JSC::B3::is32Bit): Deleted.
1122         * b3/B3LowerToAir.cpp:
1123         (JSC::B3::Air::LowerToAir::appendTrapping):
1124         (JSC::B3::Air::LowerToAir::appendCAS):
1125         (JSC::B3::Air::LowerToAir::appendGeneralAtomic):
1126         * dfg/DFGAbstractInterpreterInlines.h:
1127         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1128         * dfg/DFGByteCodeParser.cpp:
1129         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1130         * dfg/DFGClobberize.h:
1131         (JSC::DFG::clobberize):
1132         * dfg/DFGDoesGC.cpp:
1133         (JSC::DFG::doesGC):
1134         * dfg/DFGFixupPhase.cpp:
1135         (JSC::DFG::FixupPhase::fixupNode):
1136         * dfg/DFGNode.h:
1137         (JSC::DFG::Node::hasHeapPrediction):
1138         (JSC::DFG::Node::hasArrayMode):
1139         * dfg/DFGNodeType.h:
1140         (JSC::DFG::isAtomicsIntrinsic):
1141         (JSC::DFG::numExtraAtomicsArgs):
1142         * dfg/DFGPredictionPropagationPhase.cpp:
1143         * dfg/DFGSSALoweringPhase.cpp:
1144         (JSC::DFG::SSALoweringPhase::handleNode):
1145         * dfg/DFGSafeToExecute.h:
1146         (JSC::DFG::safeToExecute):
1147         * dfg/DFGSpeculativeJIT.cpp:
1148         (JSC::DFG::SpeculativeJIT::loadFromIntTypedArray):
1149         (JSC::DFG::SpeculativeJIT::setIntTypedArrayLoadResult):
1150         (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
1151         (JSC::DFG::SpeculativeJIT::getIntTypedArrayStoreOperand):
1152         (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
1153         * dfg/DFGSpeculativeJIT.h:
1154         (JSC::DFG::SpeculativeJIT::callOperation):
1155         * dfg/DFGSpeculativeJIT32_64.cpp:
1156         (JSC::DFG::SpeculativeJIT::compile):
1157         * dfg/DFGSpeculativeJIT64.cpp:
1158         (JSC::DFG::SpeculativeJIT::compile):
1159         * ftl/FTLAbstractHeapRepository.cpp:
1160         (JSC::FTL::AbstractHeapRepository::decorateFencedAccess):
1161         (JSC::FTL::AbstractHeapRepository::computeRangesAndDecorateInstructions):
1162         * ftl/FTLAbstractHeapRepository.h:
1163         * ftl/FTLCapabilities.cpp:
1164         (JSC::FTL::canCompile):
1165         * ftl/FTLLowerDFGToB3.cpp:
1166         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1167         (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsReadModifyWrite):
1168         (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsIsLockFree):
1169         (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
1170         (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
1171         (JSC::FTL::DFG::LowerDFGToB3::pointerIntoTypedArray):
1172         (JSC::FTL::DFG::LowerDFGToB3::loadFromIntTypedArray):
1173         (JSC::FTL::DFG::LowerDFGToB3::storeType):
1174         (JSC::FTL::DFG::LowerDFGToB3::setIntTypedArrayLoadResult):
1175         (JSC::FTL::DFG::LowerDFGToB3::getIntTypedArrayStoreOperand):
1176         (JSC::FTL::DFG::LowerDFGToB3::vmCall):
1177         * ftl/FTLOutput.cpp:
1178         (JSC::FTL::Output::store):
1179         (JSC::FTL::Output::store32As8):
1180         (JSC::FTL::Output::store32As16):
1181         (JSC::FTL::Output::atomicXchgAdd):
1182         (JSC::FTL::Output::atomicXchgAnd):
1183         (JSC::FTL::Output::atomicXchgOr):
1184         (JSC::FTL::Output::atomicXchgSub):
1185         (JSC::FTL::Output::atomicXchgXor):
1186         (JSC::FTL::Output::atomicXchg):
1187         (JSC::FTL::Output::atomicStrongCAS):
1188         * ftl/FTLOutput.h:
1189         (JSC::FTL::Output::store32):
1190         (JSC::FTL::Output::store64):
1191         (JSC::FTL::Output::storePtr):
1192         (JSC::FTL::Output::storeFloat):
1193         (JSC::FTL::Output::storeDouble):
1194         * jit/JITOperations.h:
1195         * runtime/AtomicsObject.cpp:
1196         (JSC::atomicsFuncAdd):
1197         (JSC::atomicsFuncAnd):
1198         (JSC::atomicsFuncCompareExchange):
1199         (JSC::atomicsFuncExchange):
1200         (JSC::atomicsFuncIsLockFree):
1201         (JSC::atomicsFuncLoad):
1202         (JSC::atomicsFuncOr):
1203         (JSC::atomicsFuncStore):
1204         (JSC::atomicsFuncSub):
1205         (JSC::atomicsFuncWait):
1206         (JSC::atomicsFuncWake):
1207         (JSC::atomicsFuncXor):
1208         (JSC::operationAtomicsAdd):
1209         (JSC::operationAtomicsAnd):
1210         (JSC::operationAtomicsCompareExchange):
1211         (JSC::operationAtomicsExchange):
1212         (JSC::operationAtomicsIsLockFree):
1213         (JSC::operationAtomicsLoad):
1214         (JSC::operationAtomicsOr):
1215         (JSC::operationAtomicsStore):
1216         (JSC::operationAtomicsSub):
1217         (JSC::operationAtomicsXor):
1218         * runtime/AtomicsObject.h:
1219
1220 2017-04-19  Youenn Fablet  <youenn@apple.com>
1221
1222         [Mac] Allow customizing H264 encoder
1223         https://bugs.webkit.org/show_bug.cgi?id=170829
1224
1225         Reviewed by Alex Christensen.
1226
1227         * Configurations/FeatureDefines.xcconfig:
1228
1229 2017-04-19  Michael Saboff  <msaboff@apple.com>
1230
1231         Tune GC related JSC options for iOS
1232         https://bugs.webkit.org/show_bug.cgi?id=171019
1233
1234         Reviewed by Mark Lam.
1235
1236         Always set these GC options on iOS.
1237
1238         * runtime/Options.cpp:
1239         (JSC::overrideDefaults):
1240
1241 2017-04-19  JF Bastien  <jfbastien@apple.com>
1242
1243         WebAssembly: fast memory cleanups
1244         https://bugs.webkit.org/show_bug.cgi?id=170909
1245
1246         Reviewed by Saam Barati.
1247
1248         * b3/B3LowerToAir.cpp: correct comment, and make wasm-independent
1249         (JSC::B3::Air::LowerToAir::lower):
1250         * b3/B3Procedure.h:
1251         * b3/B3Validate.cpp:
1252         * b3/B3Value.cpp:
1253         (JSC::B3::Value::effects):
1254         * b3/B3WasmBoundsCheckValue.cpp: have the creator pass in a
1255         maximum, so we don't have to know so much about wasm here
1256         (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
1257         (JSC::B3::WasmBoundsCheckValue::cloneImpl):
1258         (JSC::B3::WasmBoundsCheckValue::dumpMeta):
1259         * b3/B3WasmBoundsCheckValue.h:
1260         (JSC::B3::WasmBoundsCheckValue::boundsType):
1261         (JSC::B3::WasmBoundsCheckValue::bounds):
1262         * b3/air/AirCode.h:
1263         * b3/air/AirCustom.h:
1264         (JSC::B3::Air::WasmBoundsCheckCustom::generate):
1265         * b3/testb3.cpp:
1266         (JSC::B3::testWasmBoundsCheck):
1267         * wasm/WasmB3IRGenerator.cpp:
1268         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1269         (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
1270         (JSC::Wasm::createJSToWasmWrapper): remove dead code
1271         * wasm/WasmMemory.cpp: don't GC if no memory could possibly be free'd
1272         (JSC::Wasm::Memory::initializePreallocations): verbose-only code,
1273         and copy-pasta bug
1274
1275 2017-04-19  Mark Lam  <mark.lam@apple.com>
1276
1277         B3StackmapSpecial should handle when stackmap values are not recoverable from a Def'ed arg.
1278         https://bugs.webkit.org/show_bug.cgi?id=170973
1279         <rdar://problem/30318657>
1280
1281         Reviewed by Filip Pizlo.
1282
1283         In the event of an arithmetic overflow on a binary sub instruction (where the
1284         result register is same as one of the operand registers), the CheckSub FTL
1285         operation will try to recover the original value in the clobbered result register.
1286
1287         This recover is done by adding the other operand value to the result register.
1288         However, this recovery method only works if the width of the original value in
1289         the result register is less or equal to the width of the expected result.  If the
1290         width of the original operand value (e.g. a JSInt32) is wider than the result
1291         (e.g. a machine Int32), then the sub operation would have zero extended the
1292         result and cleared the upper 32-bits of the result register.  Recovery by adding
1293         back the other operand will not restore the JSValue tag in the upper word.
1294
1295         This poses a problem if the stackmap value for the operand relies on that same
1296         clobbered register.
1297
1298         The fix is to detect this potential scenario (i.e. width of the Def's arg < width
1299         of a stackmap value).  If this condition is detected, we'll declare the stackmap
1300         value to be LateColdUse to ensure that the register allocator gives it a
1301         different register if needed so that it's not dependent on the clobbered register.
1302
1303         * b3/B3CheckSpecial.cpp:
1304         (JSC::B3::CheckSpecial::forEachArg):
1305         * b3/B3PatchpointSpecial.cpp:
1306         (JSC::B3::PatchpointSpecial::forEachArg):
1307         * b3/B3StackmapSpecial.cpp:
1308         (JSC::B3::StackmapSpecial::forEachArgImpl):
1309         * b3/B3StackmapSpecial.h:
1310
1311 2017-04-19  JF Bastien  <jfbastien@apple.com>
1312
1313         Unreviewed, rolling out r215520.
1314
1315         Broke Debian 8
1316
1317         Reverted changeset:
1318
1319         "[INTL] Implement Intl.DateTimeFormat.prototype.formatToParts"
1320         https://bugs.webkit.org/show_bug.cgi?id=169458
1321         http://trac.webkit.org/changeset/215520
1322
1323 2017-04-19  JF Bastien  <jfbastien@apple.com>
1324
1325         WebAssembly: limit slow memories
1326         https://bugs.webkit.org/show_bug.cgi?id=170825
1327
1328         Reviewed by Saam Barati.
1329
1330         We limits the number of fast memories, partly because ASLR. The
1331         code then falls back to slow memories. It first tries to virtually
1332         allocated any declared maximum (and in there, physically the
1333         initial), and if that fails it tries to physically allocate the
1334         initial without any extra.
1335
1336         This can still be used to cause a bunch of virtual
1337         allocation. This patch imposes soft limit on slow memories as
1338         well. The total virtual maximum for slow memories is set at the
1339         same (theoretical) value as that for fast memories.
1340
1341         Anything exceeding that limit causes allocation/grow to fail.
1342
1343         * wasm/WasmMemory.cpp:
1344
1345 2017-04-19  JF Bastien  <jfbastien@apple.com>
1346
1347         Cannot compile JavaScriptCore/runtime/VMTraps.cpp on FreeBSD because std::pair has a non-trivial copy constructor
1348         https://bugs.webkit.org/show_bug.cgi?id=170875
1349
1350         Reviewed by Mark Lam.
1351
1352         WTF::ExpectedDetail::ConstexprBase doesn't have a user-defined
1353         copy constructor, and its implicitly-defined copy constructor is
1354         deleted because the default std::pair implementation on FreeBSD
1355         has a non-trivial copy constructor. /usr/include/c++/v1/__config
1356         says _LIBCPP_TRIVIAL_PAIR_COPY_CTOR is disabled in order to keep
1357         ABI compatibility:
1358         https://svnweb.freebsd.org/changeset/base/261801.
1359
1360         That's a huge bummer, and I'm not a fan of broken stdlibs, but in
1361         this case it's pretty nice to have a custom named type anyways and
1362         costs nothing.
1363
1364         * runtime/VMTraps.cpp:
1365         (JSC::findActiveVMAndStackBounds):
1366         (JSC::handleSigusr1):
1367         (JSC::handleSigtrap):
1368
1369 2017-04-19  Andy VanWagoner  <thetalecrafter@gmail.com>
1370
1371         [INTL] Implement Intl.DateTimeFormat.prototype.formatToParts
1372         https://bugs.webkit.org/show_bug.cgi?id=169458
1373
1374         Reviewed by JF Bastien.
1375
1376         Use udat_formatForFields to iterate through the parts of a formatted date string.
1377
1378         * icu/unicode/udat.h: Update to 55.1.
1379         * icu/unicode/ufieldpositer.h: Added from 55.1.
1380         * runtime/IntlDateTimeFormat.cpp:
1381         (JSC::IntlDateTimeFormat::partTypeString): Convert UDateFormatField to string.
1382         (JSC::IntlDateTimeFormat::formatToParts): Return parts of formatted date string.
1383         * runtime/IntlDateTimeFormat.h:
1384         * runtime/IntlDateTimeFormatPrototype.cpp:
1385         (JSC::IntlDateTimeFormatPrototypeFuncFormatToParts): Add prototype function formatToParts.
1386
1387 2017-04-19  JF Bastien  <jfbastien@apple.com>
1388
1389         WebAssembly: don't expose any WebAssembly JS object if JIT is off
1390         https://bugs.webkit.org/show_bug.cgi?id=170782
1391
1392         Reviewed by Saam Barati.
1393
1394         It's unexpected that we expose the global WebAssembly object if no
1395         JIT is present because it can't be used to compile or
1396         instantiate. Other APIs such as Memory should also be Inaccessible
1397         in those circumstances.
1398
1399         Also ensure that we don't pre-allocate fast memories if
1400         WebAssembly won't be used, and don't mark our intention to use a
1401         fast TLS slot for WebAssembly.
1402
1403         * runtime/Options.cpp:
1404         (JSC::recomputeDependentOptions):
1405
1406 2017-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1407
1408         r211670 broke double to int conversion.
1409         https://bugs.webkit.org/show_bug.cgi?id=170961
1410
1411         Reviewed by Mark Lam.
1412
1413         In this patch, we take a template parameter way.
1414         While it reduces duplicate code, it effectively produces
1415         optimized code for operationToInt32SensibleSlow,
1416         and fixes kraken pbkdf2 regression on Linux.
1417
1418         And this patch also fixes undefined behavior by changing
1419         int32_t to uint32_t. If exp is 31, missingOne is 1 << 31,
1420         INT32_MIN. Thus missingOne - 1 will cause int32_t overflow,
1421         and it is an undefined behavior.
1422
1423         * runtime/MathCommon.cpp:
1424         (JSC::operationToInt32SensibleSlow):
1425         * runtime/MathCommon.h:
1426         (JSC::toInt32Internal):
1427         (JSC::toInt32):
1428
1429 2017-04-18  Mark Lam  <mark.lam@apple.com>
1430
1431         r211670 broke double to int conversion.
1432         https://bugs.webkit.org/show_bug.cgi?id=170961
1433         <rdar://problem/31687696>
1434
1435         Reviewed by Yusuke Suzuki.
1436
1437         This is because operationToInt32SensibleSlow() assumes that left shifts of greater
1438         than 31 bits on an 31-bit value will produce a 0.  However, the spec says that
1439         "if the value of the right operand is negative or is greater or equal to the
1440         number of bits in the promoted left operand, the behavior is undefined."
1441         See http://en.cppreference.com/w/cpp/language/operator_arithmetic#Bitwise_shift_operators.
1442
1443         This patch fixes this by restoring the check to prevent a shift of greater than
1444         31 bits.  It also consolidates the optimization in operationToInt32SensibleSlow()
1445         back into toInt32() so that we don't have 2 copies of the same code with only a
1446         slight variation.
1447
1448         JSC benchmarks shows that performance is neutral with this patch.
1449
1450         * dfg/DFGSpeculativeJIT.cpp:
1451         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
1452         * ftl/FTLLowerDFGToB3.cpp:
1453         (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32):
1454         * runtime/MathCommon.cpp:
1455         (JSC::operationToInt32SensibleSlow): Deleted.
1456         * runtime/MathCommon.h:
1457         (JSC::toInt32):
1458
1459 2017-04-18  Oleksandr Skachkov  <gskachkov@gmail.com>
1460
1461         [ES6]. Implement Annex B.3.3 function hoisting rules for eval
1462         https://bugs.webkit.org/show_bug.cgi?id=163208
1463
1464         Reviewed by Saam Barati.
1465
1466         Current patch implements Annex B.3.3 that is related to 
1467         hoisting of function declaration in eval. 
1468         https://tc39.github.io/ecma262/#sec-web-compat-evaldeclarationinstantiation
1469         Function declaration in eval should create variable with 
1470         function name in function scope where eval is invoked 
1471         or bind to variable if it declared outside of the eval. 
1472         If variable is created it can be removed by 'delete a;' command. 
1473         If eval is invoke in block scope that contains let/const 
1474         variable with the same name as function declaration 
1475         we do not bind. This patch leads to the following behavior: 
1476         '''
1477         function foo() {
1478            {
1479              print(boo); // undefined
1480              eval('{ function boo() {}}');
1481              print(boo); // function boo() {}
1482            }
1483            print(boo); // function boo() {}
1484         }
1485
1486         function foobar() {
1487           { 
1488             let boo = 10;
1489             print(boo); // 10;
1490             eval('{ function boo() {}}');
1491             print(boo); // 10;
1492           }
1493           print(boo) // 10
1494         }
1495
1496         function bar() {
1497            {
1498               var boo = 10;
1499               print(boo); // 10
1500               eval('{ function boo() {} }'); 
1501               print(boo); // function boo() {}
1502            }
1503            print(boo); // function boo() {}
1504         }       
1505         
1506         function bas() {
1507             {
1508                  let boo = 10;
1509                  eval(' { function boo() {} } ');
1510                  print(boo); // 10
1511             }
1512             print(boo); //Reference Error
1513         }
1514         '''
1515
1516         Current implementation relies on already implemented 
1517         'hoist function in sloppy mode' feature, with small changes.
1518         In short it works in following way: during hoisting of function 
1519         with name S in eval, we are looking for first scope that 
1520         contains space for variable with name S and if this scope 
1521         has var type we bind function there
1522
1523         To implement this feature was added bytecode ops:
1524         op_resolve_scope_for_hoisting_func_decl_in_eval - get variable scope 
1525         or return undefined if variable can't be binded there.
1526
1527         There is a corner case, hoist function in eval within catch block,
1528         that is not covered by this patch, and will be fixed in 
1529         https://bugs.webkit.org/show_bug.cgi?id=168184
1530
1531         * bytecode/BytecodeDumper.cpp:
1532         (JSC::BytecodeDumper<Block>::dumpBytecode):
1533         * bytecode/BytecodeList.json:
1534         * bytecode/BytecodeUseDef.h:
1535         (JSC::computeUsesForBytecodeOffset):
1536         (JSC::computeDefsForBytecodeOffset):
1537         * bytecode/CodeBlock.cpp:
1538         (JSC::CodeBlock::finalizeLLIntInlineCaches):
1539         * bytecode/EvalCodeBlock.h:
1540         (JSC::EvalCodeBlock::functionHoistingCandidate):
1541         (JSC::EvalCodeBlock::numFunctionHoistingCandidates):
1542         * bytecode/UnlinkedEvalCodeBlock.h:
1543         * bytecompiler/BytecodeGenerator.cpp:
1544         (JSC::BytecodeGenerator::BytecodeGenerator):
1545         (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
1546         (JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval):
1547         * bytecompiler/BytecodeGenerator.h:
1548         * dfg/DFGAbstractInterpreterInlines.h:
1549         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1550         * dfg/DFGByteCodeParser.cpp:
1551         (JSC::DFG::ByteCodeParser::parseBlock):
1552         * dfg/DFGCapabilities.cpp:
1553         (JSC::DFG::capabilityLevel):
1554         * dfg/DFGClobberize.h:
1555         (JSC::DFG::clobberize):
1556         * dfg/DFGDoesGC.cpp:
1557         (JSC::DFG::doesGC):
1558         * dfg/DFGFixupPhase.cpp:
1559         (JSC::DFG::FixupPhase::fixupNode):
1560         * dfg/DFGNode.h:
1561         (JSC::DFG::Node::hasIdentifier):
1562         * dfg/DFGNodeType.h:
1563         * dfg/DFGOperations.cpp:
1564         * dfg/DFGOperations.h:
1565         * dfg/DFGPredictionPropagationPhase.cpp:
1566         * dfg/DFGSafeToExecute.h:
1567         (JSC::DFG::safeToExecute):
1568         * dfg/DFGSpeculativeJIT.cpp:
1569         (JSC::DFG::SpeculativeJIT::compileResolveScopeForHoistingFuncDeclInEval):
1570         * dfg/DFGSpeculativeJIT.h:
1571         (JSC::DFG::SpeculativeJIT::callOperation):
1572         * dfg/DFGSpeculativeJIT32_64.cpp:
1573         (JSC::DFG::SpeculativeJIT::compile):
1574         * dfg/DFGSpeculativeJIT64.cpp:
1575         (JSC::DFG::SpeculativeJIT::compile):
1576         * ftl/FTLCapabilities.cpp:
1577         (JSC::FTL::canCompile):
1578         * ftl/FTLLowerDFGToB3.cpp:
1579         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1580         (JSC::FTL::DFG::LowerDFGToB3::compileResolveScopeForHoistingFuncDeclInEval):
1581         * interpreter/Interpreter.cpp:
1582         (JSC::Interpreter::execute):
1583         * jit/JIT.cpp:
1584         (JSC::JIT::privateCompileMainPass):
1585         * jit/JIT.h:
1586         * jit/JITOperations.h:
1587         * jit/JITPropertyAccess.cpp:
1588         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval):
1589         * jit/JITPropertyAccess32_64.cpp:
1590         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval):
1591         * llint/LowLevelInterpreter.asm:
1592         * parser/Parser.cpp:
1593         (JSC::Parser<LexerType>::parseFunctionDeclarationStatement):
1594         * parser/Parser.h:
1595         (JSC::Scope::getSloppyModeHoistedFunctions):
1596         (JSC::Parser::declareFunction):
1597         * runtime/CommonSlowPaths.cpp:
1598         (JSC::SLOW_PATH_DECL):
1599         * runtime/CommonSlowPaths.h:
1600         * runtime/EvalExecutable.h:
1601         (JSC::EvalExecutable::numFunctionHoistingCandidates):
1602         (JSC::EvalExecutable::numTopLevelFunctionDecls):
1603         (JSC::EvalExecutable::numberOfFunctionDecls): Deleted.
1604         * runtime/JSScope.cpp:
1605         (JSC::JSScope::resolve):
1606         (JSC::JSScope::resolveScopeForHoistingFuncDeclInEval):
1607         * runtime/JSScope.h:
1608
1609 2017-04-18  Saam Barati  <sbarati@apple.com>
1610
1611         Follow up to address Mark's comments after r215453
1612
1613         Rubber stamped by Mark Lam.
1614
1615         This patch chooses better names for things, adhering to Mark's suggestions
1616         in https://bugs.webkit.org/show_bug.cgi?id=139847
1617
1618         * bytecompiler/NodesCodegen.cpp:
1619         (JSC::CallFunctionCallDotNode::emitBytecode):
1620         (JSC::ApplyFunctionCallDotNode::emitBytecode):
1621         * parser/NodeConstructors.h:
1622         (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode):
1623         (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode):
1624         * parser/Nodes.h:
1625         * parser/Parser.cpp:
1626         (JSC::recordCallOrApplyDepth):
1627         (JSC::Parser<LexerType>::parseMemberExpression):
1628         * parser/Parser.h:
1629         (JSC::Parser::CallOrApplyDepthScope::CallOrApplyDepthScope):
1630         (JSC::Parser::CallOrApplyDepthScope::distanceToInnermostChild):
1631         (JSC::Parser::CallOrApplyDepthScope::~CallOrApplyDepthScope):
1632         (JSC::Parser::CallOrApplyDepth::CallOrApplyDepth): Deleted.
1633         (JSC::Parser::CallOrApplyDepth::maxChildDepth): Deleted.
1634         (JSC::Parser::CallOrApplyDepth::~CallOrApplyDepth): Deleted.
1635
1636 2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>
1637
1638         [DFG] Convert ValueAdd(Int32, String) => MakeRope(ToString(Int32), String)
1639         https://bugs.webkit.org/show_bug.cgi?id=170943
1640
1641         Reviewed by Geoffrey Garen.
1642
1643         This patch converts ValueAdd(Int32, String) to MakeRope(ToString(Int32), String).
1644         This has 2 great features.
1645
1646         1. MakeRope(ToString(Int32), String) is less clobbering.
1647
1648         While ValueAdd ends up calling functions, VM knows much about MakeRope(ToString(Int32), String)
1649         and VM knows it is less clobbering. It encourages LICM and other operations that is conservatively
1650         executed because of ValueAdd's clobbering.
1651
1652         2. Simply, MakeRope(ToString(Int32), String) is faster than ValueAdd.
1653
1654         While ValueAdd ends up calling a generic function, our ToString(Int32) calls well-optimized toString
1655         operation. And later, MakeRope can fall into the fast path that just takes a string from a free list.
1656         It is simply faster than ValueAdd.
1657
1658         We ensure that this patch shows performance improvement in attached benchmarks.
1659
1660                                                         baseline                  patched
1661
1662             number-to-string-with-add-empty         16.2763+-3.3930     ^     10.3142+-1.0967        ^ definitely 1.5780x faster
1663             number-to-string-with-add-in-loop      168.7621+-10.9738    ^     15.5307+-3.3179        ^ definitely 10.8664x faster
1664             number-to-string-with-add               18.8557+-4.8292           11.6901+-2.5650          might be 1.6130x faster
1665
1666         In SixSpeed,
1667
1668                                                baseline                  patched
1669
1670             template_string_tag.es5       200.1027+-20.6871    ^     25.7925+-11.4052       ^ definitely 7.7582x faster
1671             template_string_tag.es6       331.3913+-12.1750    ^    286.6958+-26.0441       ^ definitely 1.1559x faster
1672             for-of-array.es5              412.4344+-23.2517    ^    272.8707+-47.2118       ^ definitely 1.5115x faster
1673             for-of-array.es6              504.0082+-65.5045    ^    300.3277+-12.8193       ^ definitely 1.6782x faster
1674
1675         * dfg/DFGFixupPhase.cpp:
1676         (JSC::DFG::FixupPhase::fixupNode):
1677         (JSC::DFG::FixupPhase::createToString):
1678         * dfg/DFGPredictionPropagationPhase.cpp:
1679
1680 2017-04-18  Michael Saboff  <msaboff@apple.com>
1681
1682         REGRESSION(215272): microbenchmark/seal-and-do-work and microbenchmark/freeze-and-do-work are 27x slower
1683         https://bugs.webkit.org/show_bug.cgi?id=170881
1684
1685         Reviewed by Saam Barati.
1686
1687         * runtime/ObjectConstructor.cpp:
1688         (JSC::objectConstructorSeal):
1689         (JSC::objectConstructorFreeze):
1690         Restored fast paths for final objects that don't have indexed properties.
1691
1692 2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>
1693
1694         [DFG] Use Phantom for base instead of getter when inlining intrinsic getter
1695         https://bugs.webkit.org/show_bug.cgi?id=170947
1696
1697         Reviewed by Saam Barati.
1698
1699         getter does not need to be live after OSR Exit.
1700
1701         * dfg/DFGByteCodeParser.cpp:
1702         (JSC::DFG::ByteCodeParser::handleGetById):
1703
1704 2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>
1705
1706         Unreviewed, follow-up patch after r215459
1707         https://bugs.webkit.org/show_bug.cgi?id=170940
1708
1709         Reviewed by Filip Pizlo.
1710
1711         CheckCell can cause OSRExit. Thus Phantom should be placed after CheckCell.
1712
1713         * dfg/DFGByteCodeParser.cpp:
1714         (JSC::DFG::ByteCodeParser::emitFunctionChecks):
1715         (JSC::DFG::ByteCodeParser::handleGetById):
1716
1717 2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>
1718
1719         [DFG] Drop unknown use of CheckCell's child2 to work ObjectAllocationSinking for Array iterator object
1720         https://bugs.webkit.org/show_bug.cgi?id=170940
1721
1722         Reviewed by Filip Pizlo.
1723
1724         The second argument of CheckCell is not used in meaningful way. It is just *use* the node.
1725         The problem is that it effectively *use* the child2 in ObjectAllocationSinking phase, and
1726         prevent us from eliminating object allocations. Actually, it materializes Array iterator
1727         when inlining `next()`. Instead, we should use Phantom in such a case.
1728
1729         It improves destructuring.es6 in SixSpeed 2.5x.
1730
1731         destructuring.es6      308.5184+-25.3490    ^    119.5680+-15.0520       ^ definitely 2.5803x faster
1732
1733         Note that SixSpeed tested in arewefastyet executes all the tests in one process while our SixSpeed
1734         tests each one in isolated way.
1735
1736         * dfg/DFGByteCodeParser.cpp:
1737         (JSC::DFG::ByteCodeParser::emitFunctionChecks):
1738         (JSC::DFG::ByteCodeParser::handleGetById):
1739
1740 2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>
1741
1742         [JSC][GTK] glib RunLoop does not accept negative start interval
1743         https://bugs.webkit.org/show_bug.cgi?id=170775
1744
1745         Reviewed by Saam Barati.
1746
1747         * heap/GCActivityCallback.cpp:
1748         (JSC::GCActivityCallback::scheduleTimer):
1749
1750 2017-04-17  Saam Barati  <sbarati@apple.com>
1751
1752         BytecodeGenerator ".call" and ".apply" is exponential in nesting depth
1753         https://bugs.webkit.org/show_bug.cgi?id=139847
1754         <rdar://problem/19321122>
1755
1756         Reviewed by Oliver Hunt.
1757
1758         The BytecodeGenerator's .apply(...) and .call(...) code would
1759         emit bytecode for the evaluation of its arguments twice. This
1760         is exponential, specifically, 2^n, where n is the nesting depth of
1761         .call(...) or .apply(...) inside other .call(...) or .apply(...).
1762         
1763         The reason we emit code for the arguments twice is that we try
1764         to emit efficient code for when .call or .apply is Function.prototype.call
1765         or Function.prototype.apply. Because of this, we compare .call/.apply to
1766         Function.prototype.call/.apply, and if they're the same, we emit a specialized
1767         function call in bytecode. Otherwise, we emit the generalized version.
1768         
1769         This patch makes it so that each .call(...) and .apply(...) records
1770         its max inner nesting depth. Then, we only perform the optimization
1771         for the bottom k (where k = 6) layers of the nesting tree. The reason we
1772         apply the optimization to the bottom k layers instead of top k layers
1773         is that we'll produce less code this way.
1774
1775         * bytecompiler/NodesCodegen.cpp:
1776         (JSC::CallFunctionCallDotNode::emitBytecode):
1777         (JSC::ApplyFunctionCallDotNode::emitBytecode):
1778         * parser/ASTBuilder.h:
1779         (JSC::ASTBuilder::makeFunctionCallNode):
1780         * parser/NodeConstructors.h:
1781         (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode):
1782         (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode):
1783         * parser/Nodes.h:
1784         * parser/Parser.cpp:
1785         (JSC::recordCallOrApplyDepth):
1786         (JSC::Parser<LexerType>::parseMemberExpression):
1787         * parser/Parser.h:
1788         (JSC::Parser::CallOrApplyDepth::CallOrApplyDepth):
1789         (JSC::Parser::CallOrApplyDepth::maxChildDepth):
1790         (JSC::Parser::CallOrApplyDepth::~CallOrApplyDepth):
1791         * parser/SyntaxChecker.h:
1792         (JSC::SyntaxChecker::makeFunctionCallNode):
1793
1794 2017-04-17  Mark Lam  <mark.lam@apple.com>
1795
1796         JSArray::appendMemcpy() needs to handle copying from Undecided indexing type too.
1797         https://bugs.webkit.org/show_bug.cgi?id=170896
1798         <rdar://problem/31651319>
1799
1800         Reviewed by JF Bastien and Keith Miller.
1801
1802         * runtime/JSArray.cpp:
1803         (JSC::JSArray::appendMemcpy):
1804
1805 2017-04-17  Joseph Pecoraro  <pecoraro@apple.com>
1806
1807         Web Inspector: Doesn't show size of compressed content correctly
1808         https://bugs.webkit.org/show_bug.cgi?id=155112
1809         <rdar://problem/25006728>
1810
1811         Reviewed by Alex Christensen and Timothy Hatcher.
1812
1813         * inspector/protocol/Network.json:
1814         New, exact size metrics, available after the load completes.
1815
1816 2017-04-17  Youenn Fablet  <youenn@apple.com>
1817
1818         Disable outdated WritableStream API
1819         https://bugs.webkit.org/show_bug.cgi?id=170749
1820         <rdar://problem/31446233>
1821
1822         Reviewed by Alex Christensen.
1823
1824         * Configurations/FeatureDefines.xcconfig:
1825
1826 2017-04-17  Yusuke Suzuki  <utatane.tea@gmail.com>
1827
1828         [JSCOnly] Fix build failures in macOS
1829         https://bugs.webkit.org/show_bug.cgi?id=170887
1830
1831         Reviewed by Alex Christensen.
1832
1833         Align ICU header configuration to MacCMake port.
1834
1835         * PlatformJSCOnly.cmake:
1836
1837 2017-04-17  JF Bastien  <jfbastien@apple.com>
1838
1839         B3: don't allow unsigned offsets in Value
1840         https://bugs.webkit.org/show_bug.cgi?id=170692
1841
1842         Reviewed by Filip Pizlo.
1843
1844         MemoryValue and similar B3 opcode classes always expects a signed
1845         offset. Giving it an out-of-bounds unsigned offset causes
1846         implementation-defined behavior, which can cause badness as I just
1847         fixed in WebAssembly.  This patch makes it impossible to create a
1848         Value opcodes with an unsigned value, or with an overly-large
1849         value.
1850
1851         * b3/B3AtomicValue.cpp:
1852         (JSC::B3::AtomicValue::AtomicValue):
1853         * b3/B3AtomicValue.h:
1854         * b3/B3Common.h:
1855         (JSC::B3::isRepresentableAs):
1856         * b3/B3EliminateCommonSubexpressions.cpp:
1857         * b3/B3LowerToAir.cpp:
1858         (JSC::B3::Air::LowerToAir::scaleForShl):
1859         (JSC::B3::Air::LowerToAir::effectiveAddr):
1860         (JSC::B3::Air::LowerToAir::addr):
1861         (JSC::B3::Air::LowerToAir::tryAppendLea):
1862         * b3/B3MemoryValue.cpp:
1863         (JSC::B3::MemoryValue::isLegalOffsetImpl):
1864         (JSC::B3::MemoryValue::MemoryValue):
1865         * b3/B3MemoryValue.h:
1866         * b3/B3MemoryValueInlines.h:
1867         (JSC::B3::MemoryValue::isLegalOffsetImpl):
1868         * b3/B3MoveConstants.cpp:
1869         * b3/B3ReduceStrength.cpp:
1870         * b3/B3StackmapSpecial.cpp:
1871         (JSC::B3::StackmapSpecial::repForArg):
1872         * b3/B3Value.h:
1873         * b3/air/AirArg.cpp:
1874         (JSC::B3::Air::Arg::stackAddrImpl):
1875         * b3/air/AirArg.h:
1876         (JSC::B3::Air::Arg::addr):
1877         (JSC::B3::Air::Arg::stack):
1878         (JSC::B3::Air::Arg::callArg):
1879         (JSC::B3::Air::Arg::stackAddr):
1880         (JSC::B3::Air::Arg::index):
1881         (JSC::B3::Air::Arg::offset):
1882         (JSC::B3::Air::Arg::isValidAddrForm):
1883         (JSC::B3::Air::Arg::isValidIndexForm):
1884         (JSC::B3::Air::Arg::asTrustedImm32):
1885         (JSC::B3::Air::Arg::asAddress):
1886         (JSC::B3::Air::Arg::asBaseIndex):
1887         * b3/air/AirLowerStackArgs.cpp:
1888         (JSC::B3::Air::lowerStackArgs):
1889         * b3/testb3.cpp:
1890         (JSC::B3::testMulArgStore):
1891         (JSC::B3::testStore32):
1892         (JSC::B3::testStoreConstant):
1893         (JSC::B3::testStoreConstantPtr):
1894         (JSC::B3::testStoreAddLoad32):
1895         (JSC::B3::testStoreAddLoadImm32):
1896         (JSC::B3::testStoreAddLoad8):
1897         (JSC::B3::testStoreAddLoadImm8):
1898         (JSC::B3::testStoreAddLoad16):
1899         (JSC::B3::testStoreAddLoadImm16):
1900         (JSC::B3::testStoreAddLoad64):
1901         (JSC::B3::testStoreAddLoadImm64):
1902         (JSC::B3::testStoreAddLoad32Index):
1903         (JSC::B3::testStoreAddLoadImm32Index):
1904         (JSC::B3::testStoreAddLoad64Index):
1905         (JSC::B3::testStoreAddLoadImm64Index):
1906         (JSC::B3::testStoreSubLoad):
1907         (JSC::B3::testStoreAddLoadInterference):
1908         (JSC::B3::testStoreAddAndLoad):
1909         (JSC::B3::testStoreNegLoad32):
1910         (JSC::B3::testStoreNegLoadPtr):
1911         (JSC::B3::testLoadOffset):
1912         (JSC::B3::testLoadOffsetNotConstant):
1913         (JSC::B3::testLoadOffsetUsingAdd):
1914         (JSC::B3::testLoadOffsetUsingAddInterference):
1915         (JSC::B3::testLoadOffsetUsingAddNotConstant):
1916         (JSC::B3::testStoreLoadStackSlot):
1917         (JSC::B3::testLoad):
1918         (JSC::B3::testInterpreter):
1919         (JSC::B3::testTrappingStore):
1920         (JSC::B3::testTrappingLoadAddStore):
1921         (JSC::B3::testWasmAddress):
1922         * wasm/WasmB3IRGenerator.cpp:
1923         (JSC::Wasm::B3IRGenerator::fixupPointerPlusOffset):
1924         (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
1925         (JSC::Wasm::B3IRGenerator::emitLoadOp):
1926         (JSC::Wasm::B3IRGenerator::emitStoreOp):
1927
1928 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
1929
1930         test262: test262/test/built-ins/Object/prototype/toLocaleString/primitive_this_value.js
1931         https://bugs.webkit.org/show_bug.cgi?id=170882
1932
1933         Reviewed by Saam Barati.
1934
1935         * runtime/ObjectPrototype.cpp:
1936         (JSC::objectProtoFuncToLocaleString):
1937         We should be using the this value without ToObject conversion both when
1938         getting the potential accessor and calling it. In strict mode, the this
1939         value will remain its simple value, in non-strict it is still converted.
1940
1941 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
1942
1943         test262: test262/test/built-ins/isNaN/toprimitive-not-callable-throws.js
1944         https://bugs.webkit.org/show_bug.cgi?id=170888
1945
1946         Reviewed by Saam Barati.
1947
1948         * runtime/ExceptionHelpers.h:
1949         * runtime/ExceptionHelpers.cpp:
1950         (JSC::createInvalidInstanceofParameterErrorHasInstanceValueNotFunction):
1951         Fix up this function name.
1952
1953         * runtime/JSObject.cpp:
1954         (JSC::callToPrimitiveFunction):
1955         When called with @@isPrimitive, bail on undefined or null and
1956         throw a type error if the value is not callable.
1957
1958         (JSC::JSObject::toPrimitive):
1959         Use throw scope to check for exception.
1960
1961 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
1962
1963         test262: test262/test/language/expressions/tagged-template/template-object.js
1964         https://bugs.webkit.org/show_bug.cgi?id=170878
1965
1966         Reviewed by Saam Barati.
1967
1968         * runtime/JSArray.cpp:
1969         (JSC::JSArray::put):
1970         The fast path for setting an Array's length should check if length is
1971         writable before checking for and possibly throwing a RangeError.
1972
1973 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
1974
1975         test262: test262/test/built-ins/Object/getOwnPropertyNames/15.2.3.4-4-44.js
1976         https://bugs.webkit.org/show_bug.cgi?id=170879
1977
1978         Reviewed by Saam Barati.
1979
1980         * runtime/StringObject.h:
1981         * runtime/StringObject.cpp:
1982         (JSC::StringObject::getOwnPropertyNames):
1983         (JSC::StringObject::getOwnNonIndexPropertyNames):
1984         Ensure 'length' comes after all indexed properties by moving
1985         it out to the getOwnNonIndexPropertyNames method which is called
1986         inside of getOwnPropertyNames after JSObject handles indices.
1987
1988 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
1989
1990         test262: test262/test/built-ins/Date/prototype/Symbol.toPrimitive/name.js
1991         https://bugs.webkit.org/show_bug.cgi?id=170884
1992
1993         Reviewed by Yusuke Suzuki.
1994
1995         * runtime/DatePrototype.cpp:
1996         (JSC::DatePrototype::finishCreation):
1997         * runtime/FunctionPrototype.cpp:
1998         (JSC::FunctionPrototype::addFunctionProperties):
1999         * runtime/RegExpPrototype.cpp:
2000         (JSC::RegExpPrototype::finishCreation):
2001         * runtime/SymbolPrototype.cpp:
2002         (JSC::SymbolPrototype::finishCreation):
2003         Give symbol property functions proper function names.
2004         This addresses function.name but not function.toString().
2005
2006 2017-04-15  Joseph Pecoraro  <pecoraro@apple.com>
2007
2008         test262: test262/test/language/global-code/new.target-arrow.js
2009         https://bugs.webkit.org/show_bug.cgi?id=170872
2010
2011         Reviewed by Saam Barati.
2012
2013         * parser/Parser.cpp:
2014         (JSC::Parser<LexerType>::Parser):
2015         Mark the global code scope.
2016
2017         (JSC::Parser<LexerType>::parseMemberExpression):
2018         If new.target is detected in an arrow function defined in global scope
2019         throw a SyntaxError.
2020
2021         * parser/Parser.h:
2022         (JSC::Scope::Scope):
2023         (JSC::Scope::setIsGlobalCodeScope):
2024         (JSC::Scope::isGlobalCodeScope):
2025         Marker for a global code scope.
2026
2027         * parser/ParserModes.h:
2028         (JSC::isModuleParseMode):
2029         (JSC::isProgramParseMode):
2030         (JSC::isProgramOrModuleParseMode):
2031         Helper for detecting global code based on parse mode.
2032
2033 2017-04-14  Nikita Vasilyev  <nvasilyev@apple.com>
2034
2035         Web Inspector: WebSockets: messages with non-latin letters are displayed incorrectly
2036         https://bugs.webkit.org/show_bug.cgi?id=170760
2037
2038         Reviewed by Joseph Pecoraro.
2039
2040         Add payloadLength property, which is used to display size. When payloadLength is unavailable,
2041         it is calculated from payloadData by Web Inspector frontend.
2042
2043         This fixes <webkit.org/b/170609> Web Inspector: WebSockets: Transferred size is incorrect.
2044
2045         * inspector/protocol/Network.json:
2046
2047 2017-04-14  Saam Barati  <sbarati@apple.com>
2048
2049         ParseInt intrinsic in DFG backend doesn't properly flush its operands
2050         https://bugs.webkit.org/show_bug.cgi?id=170865
2051
2052         Reviewed by Mark Lam and Geoffrey Garen.
2053
2054         The DFG backend code needed to first call .gpr()/.jsValueRegs()
2055         before calling flushRegisters(), or the input JSValueOperand would
2056         not be flushed.
2057
2058         * dfg/DFGSpeculativeJIT.cpp:
2059         (JSC::DFG::SpeculativeJIT::compileParseInt):
2060
2061 2017-04-14  Mark Lam  <mark.lam@apple.com>
2062
2063         Update architectures in xcconfig files.
2064         https://bugs.webkit.org/show_bug.cgi?id=170867
2065         <rdar://problem/31628104>
2066
2067         Reviewed by Joseph Pecoraro.
2068
2069         * Configurations/Base.xcconfig:
2070         * Configurations/FeatureDefines.xcconfig:
2071         * Configurations/JavaScriptCore.xcconfig:
2072         * Configurations/ToolExecutable.xcconfig:
2073
2074 2017-04-14  Keith Miller  <keith_miller@apple.com>
2075
2076         WebAssembly: B3IRGenerator should use phis for result types
2077         https://bugs.webkit.org/show_bug.cgi?id=170863
2078
2079         Reviewed by Filip Pizlo.
2080
2081         Currently, we use variables for the result types of control flow in
2082         Wasm. We did this originally since we weren't sure that the phis we
2083         generated would be optimal. Since then, we have verified that the edges
2084         in wasm control flow ensure that each upsilon will dominate its phi
2085         so we don't need to use variables.
2086
2087         * wasm/WasmB3IRGenerator.cpp:
2088         (JSC::Wasm::B3IRGenerator::ControlData::ControlData):
2089         (JSC::Wasm::B3IRGenerator::addTopLevel):
2090         (JSC::Wasm::B3IRGenerator::addBlock):
2091         (JSC::Wasm::B3IRGenerator::addLoop):
2092         (JSC::Wasm::B3IRGenerator::unify):
2093
2094 2017-04-14  Alex Christensen  <achristensen@webkit.org>
2095
2096         Fix Windows build after r215368.
2097         https://bugs.webkit.org/show_bug.cgi?id=170641
2098
2099         * CMakeLists.txt:
2100         Add new directory containing files needed in WebCore.
2101
2102 2017-04-14  Caitlin Potter  <caitp@igalia.com>
2103
2104         [JSC] use ExpressionErrorClassifier for AwaitExpression operand
2105         https://bugs.webkit.org/show_bug.cgi?id=170844
2106
2107         Reviewed by Saam Barati.
2108
2109         In parseAssignmentExpression(), several cover grammars are handled, and
2110         use ExpressionErrorClassifier to record hints about which grammars to
2111         try.
2112
2113         In parseAwaitExpression(), the hints recorded during parsing of the
2114         operand need to be discarded, because if they propagate to the outer
2115         parseAssignmentExpression(), the hints will lead the parser down invalid
2116         branches that should be skipped.
2117
2118         This change adds an additional ExpressionErrorClassifier to
2119         parseAwaitExpression(), in order to discard hints recorded trying to
2120         parse the operand.
2121
2122         * parser/Parser.cpp:
2123         (JSC::Parser<LexerType>::parseAwaitExpression):
2124
2125 2017-04-14  Saam Barati  <sbarati@apple.com>
2126
2127         WebAssembly: There is a short window of time where a CodeBlock could be destroyed before all of its async compilation callbacks are called
2128         https://bugs.webkit.org/show_bug.cgi?id=170641
2129
2130         Reviewed by Keith Miller.
2131
2132         There is an unlikely race when a CodeBlock compilation fails,
2133         the module compiles a new CodeBlock for that memory mode, all while
2134         the CodeBlock is notifying its callbacks that it has finished.
2135         There is a chance that the Module could deref its failed CodeBlock 
2136         at that point, destroying it, before the callbacks were able to
2137         grab a Ref to the CodeBlock. This patch fixes the race by having the
2138         callbacks ref the CodeBlock.
2139
2140         This patch also has the Plan clear out all of its callbacks
2141         once it gets completed. This adds an extra defense to anybody
2142         that grabs refs to the Plan in the callback.
2143
2144         * wasm/WasmCodeBlock.cpp:
2145         (JSC::Wasm::CodeBlock::CodeBlock):
2146         (JSC::Wasm::CodeBlock::compileAsync):
2147         * wasm/WasmPlan.cpp:
2148         (JSC::Wasm::Plan::complete):
2149
2150 2017-04-13  Filip Pizlo  <fpizlo@apple.com>
2151
2152         Air::RegLiveness should be constraint-based
2153         https://bugs.webkit.org/show_bug.cgi?id=170817
2154
2155         Reviewed by Saam Barati.
2156         
2157         Previously, I changed the Air liveness analyses based on Air::Liveness<> to be
2158         constraint-based and this was a significant speed-up. Now I'm adding the same
2159         functionality to RegLiveness.
2160         
2161         This is a 1% speed-up on wasm B3 -O1 compile times.
2162         
2163         * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp:
2164         * b3/air/AirLivenessAdapter.h:
2165         (JSC::B3::Air::LivenessAdapter::LivenessAdapter):
2166         (JSC::B3::Air::LivenessAdapter::prepareToCompute):
2167         (JSC::B3::Air::LivenessAdapter::actionsAt):
2168         * b3/air/AirRegLiveness.cpp:
2169         (JSC::B3::Air::RegLiveness::RegLiveness):
2170         (JSC::B3::Air::RegLiveness::LocalCalcForUnifiedTmpLiveness::LocalCalcForUnifiedTmpLiveness):
2171         (JSC::B3::Air::RegLiveness::LocalCalcForUnifiedTmpLiveness::execute):
2172         (JSC::B3::Air::RegLiveness::LocalCalc::execute): Deleted.
2173         * b3/air/AirRegLiveness.h:
2174         (JSC::B3::Air::RegLiveness::Actions::Actions):
2175         (JSC::B3::Air::RegLiveness::LocalCalcBase::LocalCalcBase):
2176         (JSC::B3::Air::RegLiveness::LocalCalcBase::live):
2177         (JSC::B3::Air::RegLiveness::LocalCalcBase::isLive):
2178         (JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc):
2179         (JSC::B3::Air::RegLiveness::LocalCalc::execute):
2180         (JSC::B3::Air::RegLiveness::LocalCalc::live): Deleted.
2181         (JSC::B3::Air::RegLiveness::LocalCalc::isLive): Deleted.
2182
2183 2017-04-13  JF Bastien  <jfbastien@apple.com>
2184
2185         WebAssembly: fix windows build
2186         https://bugs.webkit.org/show_bug.cgi?id=170832
2187
2188         Reviewed by Mark Lam.
2189
2190         My previous patch re-declared isIOS which AssemblerCommon.h
2191         already provided, and which was already included by Options.cpp.
2192
2193         * runtime/Options.cpp:
2194
2195 2017-04-13  Saam Barati  <sbarati@apple.com>
2196
2197         WebAssembly: We should be able to postMessage a JSWebAssemblyModule
2198         https://bugs.webkit.org/show_bug.cgi?id=170573
2199
2200         Reviewed by Filip Pizlo.
2201
2202         This patch adds a callback to JSRunLoopTimer to notify
2203         clients that a timer has been set. This is used inside
2204         WorkerRunLoop in WebCore so that its RunLoop can perform
2205         an iteration when it sees that a timer got set.
2206
2207         * JavaScriptCore.xcodeproj/project.pbxproj:
2208         * runtime/JSRunLoopTimer.cpp:
2209         (JSC::JSRunLoopTimer::scheduleTimer):
2210         (JSC::JSRunLoopTimer::addTimerSetNotification):
2211         (JSC::JSRunLoopTimer::removeTimerSetNotification):
2212         * runtime/JSRunLoopTimer.h:
2213         * wasm/WasmCodeBlock.cpp:
2214         (JSC::Wasm::CodeBlock::~CodeBlock):
2215         * wasm/WasmCodeBlock.h:
2216         * wasm/WasmModule.cpp:
2217         (JSC::Wasm::Module::~Module):
2218         (JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace):
2219         (JSC::Wasm::makeValidationCallback):
2220         (JSC::Wasm::Module::validateSync):
2221         (JSC::Wasm::Module::validateAsync):
2222         (JSC::Wasm::Module::validateSyncImpl): Deleted.
2223         (JSC::Wasm::Module::makeValidationCallback): Deleted.
2224         * wasm/WasmModule.h:
2225         (JSC::Wasm::Module::validateSync): Deleted.
2226         (JSC::Wasm::Module::validateAsync): Deleted.
2227         (JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace): Deleted.
2228         (JSC::Wasm::Module::nonNullCodeBlock): Deleted.
2229         * wasm/js/JSWebAssemblyCodeBlock.cpp:
2230         (JSC::JSWebAssemblyCodeBlock::create):
2231         * wasm/js/JSWebAssemblyCodeBlock.h:
2232         (JSC::JSWebAssemblyCodeBlock::create): Deleted.
2233         * wasm/js/JSWebAssemblyModule.cpp:
2234         (JSC::JSWebAssemblyModule::source):
2235         * wasm/js/JSWebAssemblyModule.h:
2236         (JSC::JSWebAssemblyModule::source): Deleted.
2237         * wasm/js/WebAssemblyFunction.cpp:
2238         (JSC::callWebAssemblyFunction):
2239         * wasm/js/WebAssemblyModulePrototype.cpp:
2240
2241 2017-04-13  Mark Lam  <mark.lam@apple.com>
2242
2243         Should use flushDirect() when flushing the scopeRegister due to needsScopeRegister().
2244         https://bugs.webkit.org/show_bug.cgi?id=170661
2245         <rdar://problem/31579046>
2246
2247         Reviewed by Filip Pizlo.
2248
2249         Previously, we were using flush() to flush the outermost frame's scopeRegister.
2250         This is incorrect because flush() expects the VirtualRegister value passed to
2251         it to be that of the top most inlined frame.  In the event that we reach a
2252         terminal condition while inside an inlined frame, flush() will end up flushing
2253         the wrong register.  The fix is simply to use flushDirect() instead.
2254
2255         * dfg/DFGByteCodeParser.cpp:
2256         (JSC::DFG::ByteCodeParser::flush):
2257
2258 2017-04-13  Andy VanWagoner  <thetalecrafter@gmail.com>
2259
2260         Change Intl prototypes to plain objects
2261         https://bugs.webkit.org/show_bug.cgi?id=168178
2262
2263         Reviewed by JF Bastien.
2264
2265         * builtins/StringPrototype.js:
2266         (localeCompare): Create default Collator once instead of using prototype.
2267         * runtime/IntlCollatorPrototype.cpp:
2268         (JSC::IntlCollatorPrototype::IntlCollatorPrototype):
2269         * runtime/IntlCollatorPrototype.h:
2270         * runtime/IntlDateTimeFormatPrototype.cpp:
2271         (JSC::IntlDateTimeFormatPrototype::IntlDateTimeFormatPrototype):
2272         * runtime/IntlDateTimeFormatPrototype.h:
2273         * runtime/IntlNumberFormatPrototype.cpp:
2274         (JSC::IntlNumberFormatPrototype::IntlNumberFormatPrototype):
2275         * runtime/IntlNumberFormatPrototype.h:
2276         * runtime/IntlObject.cpp:
2277         (JSC::IntlObject::finishCreation): Don't set constructor on each prototype.
2278
2279 2017-04-13  Oliver Hunt  <oliver@apple.com>
2280
2281         allocationSize should use safe arithmetic by default
2282         https://bugs.webkit.org/show_bug.cgi?id=170804
2283
2284         Reviewed by JF Bastien.
2285
2286         Make all allocationSize() functions work in terms
2287         of Checked<size_t>
2288
2289         * runtime/DirectArguments.h:
2290         (JSC::DirectArguments::offsetOfSlot):
2291         (JSC::DirectArguments::allocationSize):
2292         * runtime/HashMapImpl.h:
2293         (JSC::HashMapBuffer::allocationSize):
2294         * runtime/JSArray.h:
2295         (JSC::JSArray::allocationSize):
2296         * runtime/JSArrayBufferView.h:
2297         (JSC::JSArrayBufferView::allocationSize):
2298         * runtime/JSAsyncFunction.h:
2299         (JSC::JSAsyncFunction::allocationSize):
2300         * runtime/JSFixedArray.h:
2301         (JSC::JSFixedArray::allocationSize):
2302         * runtime/JSFunction.h:
2303         (JSC::JSFunction::allocationSize):
2304         * runtime/JSGeneratorFunction.h:
2305         (JSC::JSGeneratorFunction::allocationSize):
2306         * runtime/JSModuleNamespaceObject.h:
2307         * runtime/JSObject.h:
2308         (JSC::JSFinalObject::allocationSize):
2309         * runtime/JSWrapperObject.h:
2310         (JSC::JSWrapperObject::allocationSize):
2311         * runtime/ScopedArguments.h:
2312         (JSC::ScopedArguments::allocationSize):
2313         * runtime/VM.h:
2314         (JSC::ScratchBuffer::allocationSize):
2315         * wasm/js/JSWebAssemblyCodeBlock.h:
2316         (JSC::JSWebAssemblyCodeBlock::offsetOfImportStubs):
2317         (JSC::JSWebAssemblyCodeBlock::allocationSize):
2318         * wasm/js/JSWebAssemblyInstance.h:
2319         (JSC::JSWebAssemblyInstance::allocationSize):
2320
2321 2017-04-13  JF Bastien  <jfbastien@apple.com>
2322
2323         WebAssembly: manage memory better
2324         https://bugs.webkit.org/show_bug.cgi?id=170628
2325
2326         Reviewed by Keith Miller, Michael Saboff.
2327
2328         WebAssembly fast memories weren't managed very well. This patch
2329         refactors it and puts us in a good position to further improve our
2330         fast memory handling in the future.
2331
2332         We now cache fast memories at a process granularity, but make sure
2333         that they don't consume dirty pages. We add a cap to the total
2334         number of allocated fast memories to avoid ASLR degradation.
2335
2336         We teach the GC about memories as a kind of resource it should
2337         care about because it didn't have visibility into the amount of
2338         memory each represented. This allows benchmarks which allocate
2339         memories back-to-back to reliably get fast memories 100% of the
2340         time, even on a system under load, which wasn't the case
2341         before. This reliability yields roughly 8% perf bump on x86-64
2342         WasmBench.
2343
2344         The GC heuristic is as follows: each time we allocate a fast
2345         memory we notify the GC, which then keeps track of the total
2346         number of fast memories allocated since it last GC'd. We
2347         separately keep track of the total number of fast memories which
2348         have ever existed at any point in time (cached + allocated). This
2349         is a monotonically-increasing high watermark. The GC will force a
2350         full collection if, since it last ran, half or more of the high
2351         watermark of fast memories was allocated.
2352
2353         At the same time, if we fail obtaining a fast memory from the
2354         cache we do a GC to try to find one. If that fails we'll allocate
2355         a new one (this can also fail, then we go to slow memory). This
2356         can also be improved, but it's a good start.
2357
2358         This currently disables fast memories on iOS because getting fast
2359         memories isn't a guaranteed thing. Rather, we get quite a few of
2360         them and achieve significant speedups, but benchmarks which
2361         allocate memories back-to-back end up falling behind because the
2362         GC can conservatively hold onto memories, which then yields a perf
2363         cliff. That cliff isn't reliable, WasmBench gets roughly 10 of 18
2364         fast memories when in theory it should get all of them fast (as
2365         MacOS does). The patch significantly improves the state of iOS
2366         though, and in a follow-up we could re-enable fast memories.
2367
2368         Part of this good positioning is a facility to pre-allocate fast
2369         memories very early at startup, before any fragmentation
2370         occurs. This is currently disabled but worked extremely reliably
2371         on iOS. Once we fix the above issues we'll want to re-visit and
2372         turn on pre-allocation.
2373
2374         We also avoid locking for fast memory identification when
2375         performing signal handling. I'm very nervous about acquiring locks
2376         in a signal handler because in general signals can happen when
2377         we've messed up. This isn't the case with fast memories: we're
2378         raising a signal on purpose and handling it. However this doesn't
2379         mean we won't mess up elsewhere! This will get more complicated
2380         once we add support for multiple threads sharing memories and
2381         being able to grow their memories. One example: the code calls
2382         CRASH(), which executes the following code in release:
2383
2384             *(int *)(uintptr_t)0xbbadbeef = 0;
2385
2386         This is a segfault, which our fast memory signal handler tries to
2387         handle. It does so by first figuring out whether 0xbbadbeef is in
2388         a fast memory region, reqiring a lock. If we CRASH() while holding
2389         the lock then our thread self-deadlocks, giving us no crash report
2390         and a bad user experience.
2391
2392         Avoiding a lock therefore it's not about speed or reduced
2393         contention. In fact, I'd use something else than a FIFO if these
2394         were a concern. We're also doing syscalls, which dwarf any locking
2395         cost.
2396
2397         We now only allocate 4GiB + redzone of 64k * 128 for fast memories
2398         instead of 8GiB. This patch reuses the logic from
2399         B3::WasmBoundsCheck to perform bounds checks when accesses could
2400         exceed the redzone. We'll therefore benefit from CSE goodness when
2401         it reaches WasmBoundsCheck. See bug #163469.
2402
2403         * b3/B3LowerToAir.cpp: fix a baaaaddd bug where unsigned->signed
2404         conversion allowed out-of-bounds reads by -2GiB. I'll follow-up in
2405         bug #170692 to prevent this type of bug once and for all.
2406         (JSC::B3::Air::LowerToAir::lower):
2407         * b3/B3Validate.cpp: update WasmBoundsCheck validation.
2408         * b3/B3Value.cpp:
2409         (JSC::B3::Value::effects): update WasmBoundsCheck effects.
2410         * b3/B3WasmBoundsCheckValue.cpp:
2411         (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
2412         (JSC::B3::WasmBoundsCheckValue::redzoneLimit):
2413         (JSC::B3::WasmBoundsCheckValue::dumpMeta):
2414         * b3/B3WasmBoundsCheckValue.h:
2415         (JSC::B3::WasmBoundsCheckValue::maximum):
2416         * b3/air/AirCustom.cpp:
2417         (JSC::B3::Air::WasmBoundsCheckCustom::isValidForm):
2418         * b3/testb3.cpp:
2419         (JSC::B3::testWasmBoundsCheck):
2420         * heap/Heap.cpp:
2421         (JSC::Heap::Heap):
2422         (JSC::Heap::reportWebAssemblyFastMemoriesAllocated):
2423         (JSC::Heap::webAssemblyFastMemoriesThisCycleAtThreshold):
2424         (JSC::Heap::updateAllocationLimits):
2425         (JSC::Heap::didAllocateWebAssemblyFastMemories):
2426         (JSC::Heap::shouldDoFullCollection):
2427         (JSC::Heap::collectIfNecessaryOrDefer):
2428         * heap/Heap.h:
2429         * runtime/InitializeThreading.cpp:
2430         (JSC::initializeThreading):
2431         * runtime/Options.cpp:
2432         * runtime/Options.h:
2433         * wasm/WasmB3IRGenerator.cpp:
2434         (JSC::Wasm::B3IRGenerator::fixupPointerPlusOffset):
2435         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
2436         (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
2437         (JSC::Wasm::B3IRGenerator::emitLoadOp):
2438         (JSC::Wasm::B3IRGenerator::emitStoreOp):
2439         (JSC::Wasm::createJSToWasmWrapper):
2440         * wasm/WasmFaultSignalHandler.cpp:
2441         (JSC::Wasm::trapHandler):
2442         * wasm/WasmMemory.cpp: Rewrite.
2443         (JSC::Wasm::makeString):
2444         (JSC::Wasm::Memory::initializePreallocations):
2445         (JSC::Wasm::Memory::createImpl):
2446         (JSC::Wasm::Memory::create):
2447         (JSC::Wasm::Memory::~Memory):
2448         (JSC::Wasm::Memory::fastMappedRedzoneBytes):
2449         (JSC::Wasm::Memory::fastMappedBytes):
2450         (JSC::Wasm::Memory::maxFastMemoryCount):
2451         (JSC::Wasm::Memory::addressIsInActiveFastMemory):
2452         (JSC::Wasm::Memory::grow):
2453         * wasm/WasmMemory.h:
2454         (Memory::maxFastMemoryCount):
2455         (Memory::addressIsInActiveFastMemory):
2456         * wasm/js/JSWebAssemblyInstance.cpp:
2457         (JSC::JSWebAssemblyInstance::finishCreation):
2458         (JSC::JSWebAssemblyInstance::visitChildren):
2459         (JSC::JSWebAssemblyInstance::globalMemoryByteSize):
2460         * wasm/js/JSWebAssemblyInstance.h:
2461         * wasm/js/JSWebAssemblyMemory.cpp:
2462         (JSC::JSWebAssemblyMemory::grow):
2463         (JSC::JSWebAssemblyMemory::finishCreation):
2464         (JSC::JSWebAssemblyMemory::visitChildren):
2465
2466 2017-04-13  Yusuke Suzuki  <utatane.tea@gmail.com>
2467
2468         [JSC] Use proper ifdef guard for code using MachineContext
2469         https://bugs.webkit.org/show_bug.cgi?id=170800
2470
2471         Reviewed by Carlos Alberto Lopez Perez.
2472
2473         This patch drops MachineContext use if it is not available.
2474         This situation can be considered like, building WebKit with musl.
2475         In that case, we simply disable features that rely on MachineContext.
2476         Examples are wasm fast memory, sampling profiler, and code profiling.
2477
2478         * runtime/Options.cpp:
2479         (JSC::overrideDefaults):
2480         * tools/CodeProfiling.cpp:
2481         (JSC::CodeProfiling::begin):
2482         (JSC::CodeProfiling::end):
2483         Previously, PLATFORM(GTK) is excluded. But it is not obvious why it is excluded.
2484         This patch just includes such platforms.
2485
2486         * wasm/WasmFaultSignalHandler.cpp:
2487         (JSC::Wasm::enableFastMemory):
2488
2489 2017-04-12  Dan Bernstein  <mitz@apple.com>
2490
2491         [Mac] Future-proof .xcconfig files
2492         https://bugs.webkit.org/show_bug.cgi?id=170802
2493
2494         Reviewed by Tim Horton.
2495
2496         * Configurations/Base.xcconfig:
2497         * Configurations/DebugRelease.xcconfig:
2498         * Configurations/FeatureDefines.xcconfig:
2499         * Configurations/Version.xcconfig:
2500
2501 2017-04-12  Joseph Pecoraro  <pecoraro@apple.com>
2502
2503         test262: test262/test/built-ins/NativeErrors/EvalError/proto.js
2504         https://bugs.webkit.org/show_bug.cgi?id=170668
2505
2506         Reviewed by Keith Miller.
2507
2508         * runtime/JSGlobalObject.cpp:
2509         (JSC::JSGlobalObject::init):
2510         The [[Prototype]] of NativeError Constructor's should be the %Error%.
2511         https://tc39.github.io/ecma262/#sec-properties-of-the-nativeerror-constructors
2512
2513 2017-04-12  Joseph Pecoraro  <pecoraro@apple.com>
2514
2515         test262: test262/test/language/literals/regexp/u-dec-esc.js
2516         https://bugs.webkit.org/show_bug.cgi?id=170687
2517
2518         Reviewed by Michael Saboff.
2519
2520         * yarr/YarrParser.h:
2521         (JSC::Yarr::Parser::parseEscape):
2522         * yarr/YarrPattern.cpp:
2523         (JSC::Yarr::YarrPattern::errorMessage):
2524         (JSC::Yarr::YarrPattern::compile):
2525         * yarr/YarrPattern.h:
2526         In unicoe patterns, invalid backreferences are an error.
2527
2528 2017-04-12  Filip Pizlo  <fpizlo@apple.com>
2529
2530         Move common stack allocation utilities out of AirAllocateStackByGraphColoring.cpp
2531         https://bugs.webkit.org/show_bug.cgi?id=170799
2532
2533         Reviewed by Michael Saboff and Keith Miller.
2534         
2535         When I added stack allocation to allocateRegistersByLinearScan, I reused a handful of
2536         utility functions from AirAllocateStackByGraphColoring.cpp. I accomplished this by
2537         putting their declarations in AirAllocateStackByGraphColoring.h.
2538         
2539         That was pretty weird.
2540         
2541         This patch moves a family of stack allocation helper functions out of
2542         AirAllocateStackByGraphColoring.cpp and into the new AirStackAllocation.h|cpp. The
2543         linear scan stack allocator no longer has to include the other stack allocator's
2544         header, which addresses my OCD.
2545         
2546         I moved the functions transitively reachable from the two functions that the linear
2547         scan allocator needed. This forced me to give them better names (i.e. no "fooBarImpl")
2548         and short descriptive comments. I think that such comments are useful in code that is
2549         doing a convoluted version of some theoretical concept.
2550         
2551         No behavior change.
2552
2553         * CMakeLists.txt:
2554         * JavaScriptCore.xcodeproj/project.pbxproj:
2555         * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp:
2556         * b3/air/AirAllocateStackByGraphColoring.cpp:
2557         (JSC::B3::Air::allocateStackByGraphColoring):
2558         (JSC::B3::Air::allocateEscapedStackSlots): Deleted.
2559         (JSC::B3::Air::updateFrameSizeBasedOnStackSlots): Deleted.
2560         * b3/air/AirAllocateStackByGraphColoring.h:
2561         * b3/air/AirStackAllocation.cpp: Added.
2562         (JSC::B3::Air::attemptAssignment):
2563         (JSC::B3::Air::assign):
2564         (JSC::B3::Air::allocateAndGetEscapedStackSlotsWithoutChangingFrameSize):
2565         (JSC::B3::Air::allocateEscapedStackSlots):
2566         (JSC::B3::Air::updateFrameSizeBasedOnStackSlots):
2567         * b3/air/AirStackAllocation.h: Added.
2568
2569 2017-04-12  Filip Pizlo  <fpizlo@apple.com>
2570
2571         B3 -O1 should not allocateStackByGraphColoring
2572         https://bugs.webkit.org/show_bug.cgi?id=170742
2573
2574         Reviewed by Keith Miller.
2575         
2576         One of B3 -O1's longest running phases is allocateStackByGraphColoring. One approach to
2577         this would be to make that phase cheaper. But it's weird that this phase reruns
2578         liveness after register allocation already ran liveness. If only it could reuse the
2579         liveness computed by register allocation then it would run a lot faster. At -O2, we do
2580         not want this, since we run phases between register allocation and stack allocation,
2581         and those phases are free to change the liveness of spill slots (in fact,
2582         fixObviousSpills will both shorten and lengthen live ranges because of load and store
2583         elimination, respectively). But at -O1, we don't really need to run any phases between
2584         register and stack allocation.
2585         
2586         This changes Air's backend in the following ways:
2587         
2588         - Linear scan does stack allocation. This means that we don't need to run
2589           allocateStackByGraphColoring at all. In reality, we reuse some of its innards, but
2590           we don't run the expensive part of it (liveness->interference->coalescing->coloring).
2591           This is a speed-up because we only run liveness once and reuse it for both register
2592           and stack allocation.
2593         
2594         - Phases that previously ran between register and stack allocation are taken care of,
2595           each in its own special way:
2596           
2597           -> handleCalleSaves: this is now a utility function called by both
2598              allocateStackByGraphColoring and allocateRegistersAndStackByLinearScan.
2599           
2600           -> fixObviousSpills: we didn't run this at -O1, so nothing needs to be done.
2601           
2602           -> lowerAfterRegAlloc: this needed to be able to run before stack allocation because
2603              it could change register usage (vis a vis callee saves) and it could introduce
2604              spill slots. I changed this phase to have a secondary mode for when it runs after
2605              stack allocation.
2606         
2607         - The part of allocateStackByGraphColoring that lowered stack addresses and took care
2608           of the call arg area is now a separate phase called lowerStackArgs. We run this phase
2609           regardless of optimization level. It's a cheap and general lowering.
2610         
2611         This also removes spillEverything, because we never use that phase, we never test it,
2612         and it got in the way in this refactoring.
2613         
2614         This is a 21% speed-up on wasm -O1 compile times. This does not significantly change
2615         -O1 throughput. We had already disabled allocateStack's most important optimization
2616         (spill coalescing). This probably regresses average stack frame size, but I didn't
2617         measure by how much. Stack frame size is really not that important. The algorithm in
2618         allocateStackByGraphColoring is about much more than optimal frame size; it also
2619         tries to avoid having to zero-extend 32-bit spills, it kills dead code, and of course
2620         it coalesces.
2621
2622         * CMakeLists.txt:
2623         * JavaScriptCore.xcodeproj/project.pbxproj:
2624         * b3/B3Procedure.cpp:
2625         (JSC::B3::Procedure::calleeSaveRegisterAtOffsetList):
2626         (JSC::B3::Procedure::calleeSaveRegisters): Deleted.
2627         * b3/B3Procedure.h:
2628         * b3/B3StackmapGenerationParams.cpp:
2629         (JSC::B3::StackmapGenerationParams::unavailableRegisters):
2630         * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp: Copied from Source/JavaScriptCore/b3/air/AirAllocateRegistersByLinearScan.cpp.
2631         (JSC::B3::Air::allocateRegistersAndStackByLinearScan):
2632         (JSC::B3::Air::allocateRegistersByLinearScan): Deleted.
2633         * b3/air/AirAllocateRegistersAndStackByLinearScan.h: Copied from Source/JavaScriptCore/b3/air/AirAllocateRegistersByLinearScan.h.
2634         * b3/air/AirAllocateRegistersByLinearScan.cpp: Removed.
2635         * b3/air/AirAllocateRegistersByLinearScan.h: Removed.
2636         * b3/air/AirAllocateStackByGraphColoring.cpp:
2637         (JSC::B3::Air::allocateEscapedStackSlots):
2638         (JSC::B3::Air::updateFrameSizeBasedOnStackSlots):
2639         (JSC::B3::Air::allocateStackByGraphColoring):
2640         * b3/air/AirAllocateStackByGraphColoring.h:
2641         * b3/air/AirArg.cpp:
2642         (JSC::B3::Air::Arg::stackAddr):
2643         * b3/air/AirArg.h:
2644         (JSC::B3::Air::Arg::stackAddr): Deleted.
2645         * b3/air/AirCode.cpp:
2646         (JSC::B3::Air::Code::addStackSlot):
2647         (JSC::B3::Air::Code::setCalleeSaveRegisterAtOffsetList):
2648         (JSC::B3::Air::Code::calleeSaveRegisterAtOffsetList):
2649         (JSC::B3::Air::Code::dump):
2650         * b3/air/AirCode.h:
2651         (JSC::B3::Air::Code::setStackIsAllocated):
2652         (JSC::B3::Air::Code::stackIsAllocated):
2653         (JSC::B3::Air::Code::calleeSaveRegisters):
2654         * b3/air/AirGenerate.cpp:
2655         (JSC::B3::Air::prepareForGeneration):
2656         (JSC::B3::Air::generate):
2657         * b3/air/AirHandleCalleeSaves.cpp:
2658         (JSC::B3::Air::handleCalleeSaves):
2659         * b3/air/AirHandleCalleeSaves.h:
2660         * b3/air/AirLowerAfterRegAlloc.cpp:
2661         (JSC::B3::Air::lowerAfterRegAlloc):
2662         * b3/air/AirLowerStackArgs.cpp: Added.
2663         (JSC::B3::Air::lowerStackArgs):
2664         * b3/air/AirLowerStackArgs.h: Added.
2665         * b3/testb3.cpp:
2666         (JSC::B3::testPinRegisters):
2667         * ftl/FTLCompile.cpp:
2668         (JSC::FTL::compile):
2669         * jit/RegisterAtOffsetList.h:
2670         * wasm/WasmB3IRGenerator.cpp:
2671         (JSC::Wasm::parseAndCompile):
2672
2673 2017-04-12  Michael Saboff  <msaboff@apple.com>
2674
2675         Implement Object.isFrozen() and Object.isSealed() per ECMA spec
2676         https://bugs.webkit.org/show_bug.cgi?id=170753
2677
2678         Reviewed by Mark Lam.
2679
2680         * runtime/ObjectConstructor.cpp:
2681         (JSC::testIntegrityLevel): Added local helper as described in the ECMA standard.
2682
2683         (JSC::objectConstructorSeal):
2684         (JSC::objectConstructorFreeze):
2685         Eliminated incomplete special handling of JSFinalObjects.
2686
2687         (JSC::objectConstructorIsSealed):
2688         (JSC::objectConstructorIsFrozen):
2689         Refactored to use the new testIntegrityLevel() helper.
2690
2691 2017-04-12  Yusuke Suzuki  <utatane.tea@gmail.com>
2692
2693         Use HAVE(MACHINE_CONTEXT) instead of USE(MACHINE_CONTEXT)
2694         https://bugs.webkit.org/show_bug.cgi?id=170770
2695
2696         Rubber stamped by Mark Lam.
2697
2698         * heap/MachineStackMarker.cpp:
2699         (JSC::MachineThreads::MachineThread::Registers::framePointer):
2700         (JSC::MachineThreads::MachineThread::Registers::instructionPointer):
2701         (JSC::MachineThreads::MachineThread::Registers::llintPC):
2702         * runtime/MachineContext.h:
2703         (JSC::MachineContext::stackPointer):
2704         (JSC::MachineContext::framePointer):
2705         (JSC::MachineContext::instructionPointer):
2706         (JSC::MachineContext::argumentPointer<1>):
2707         (JSC::MachineContext::llintInstructionPointer):
2708
2709 2017-04-12  Yusuke Suzuki  <utatane.tea@gmail.com>
2710
2711         [JSC] Clean up heap/MachineStackMarker by introducing USE(MACHINE_CONTEXT)
2712         https://bugs.webkit.org/show_bug.cgi?id=170770
2713
2714         Reviewed by Mark Lam.
2715
2716         We use USE(MACHINE_CONTEXT) to clean up runtime/MachineContext.h. And
2717         we clean up heap/MachineStackMarker.cpp by using MachineContext functions.
2718
2719         * heap/MachineStackMarker.cpp:
2720         (JSC::MachineThreads::MachineThread::Registers::stackPointer):
2721         (JSC::MachineThreads::MachineThread::Registers::framePointer):
2722         (JSC::MachineThreads::MachineThread::Registers::instructionPointer):
2723         (JSC::MachineThreads::MachineThread::Registers::llintPC):
2724         * heap/MachineStackMarker.h:
2725         * runtime/MachineContext.h:
2726         (JSC::MachineContext::stackPointer):
2727         (JSC::MachineContext::framePointer):
2728         (JSC::MachineContext::instructionPointer):
2729         (JSC::MachineContext::argumentPointer<1>):
2730         (JSC::MachineContext::llintInstructionPointer):
2731
2732 2017-04-12  Yusuke Suzuki  <utatane.tea@gmail.com>
2733
2734         [WTF] Introduce Thread class and use RefPtr<Thread> and align Windows Threading implementation semantics to Pthread one
2735         https://bugs.webkit.org/show_bug.cgi?id=170502
2736
2737         Reviewed by Mark Lam.
2738
2739         * API/tests/CompareAndSwapTest.cpp:
2740         (testCompareAndSwap):
2741         * JavaScriptCore.xcodeproj/project.pbxproj:
2742         * b3/air/testair.cpp:
2743         * b3/testb3.cpp:
2744         (JSC::B3::run):
2745         * bytecode/SuperSampler.cpp:
2746         (JSC::initializeSuperSampler):
2747         * dfg/DFGWorklist.cpp:
2748         * disassembler/Disassembler.cpp:
2749         * heap/Heap.cpp:
2750         (JSC::Heap::lastChanceToFinalize):
2751         (JSC::Heap::notifyIsSafeToCollect):
2752         * heap/Heap.h:
2753         * heap/MachineStackMarker.cpp:
2754         (JSC::MachineThreads::~MachineThreads):
2755         (JSC::MachineThreads::addCurrentThread):
2756         (JSC::MachineThreads::removeThread):
2757         (JSC::MachineThreads::removeThreadIfFound):
2758         (JSC::MachineThreads::MachineThread::MachineThread):
2759         (JSC::MachineThreads::MachineThread::getRegisters):
2760         (JSC::MachineThreads::MachineThread::Registers::stackPointer):
2761         (JSC::MachineThreads::MachineThread::Registers::framePointer):
2762         (JSC::MachineThreads::MachineThread::Registers::instructionPointer):
2763         (JSC::MachineThreads::MachineThread::Registers::llintPC):
2764         (JSC::MachineThreads::MachineThread::captureStack):
2765         (JSC::MachineThreads::tryCopyOtherThreadStack):
2766         (JSC::MachineThreads::tryCopyOtherThreadStacks):
2767         (pthreadSignalHandlerSuspendResume): Deleted.
2768         (JSC::threadData): Deleted.
2769         (JSC::MachineThreads::Thread::Thread): Deleted.
2770         (JSC::MachineThreads::Thread::createForCurrentThread): Deleted.
2771         (JSC::MachineThreads::Thread::operator==): Deleted.
2772         (JSC::MachineThreads::machineThreadForCurrentThread): Deleted.
2773         (JSC::MachineThreads::ThreadData::ThreadData): Deleted.
2774         (JSC::MachineThreads::ThreadData::~ThreadData): Deleted.
2775         (JSC::MachineThreads::ThreadData::suspend): Deleted.
2776         (JSC::MachineThreads::ThreadData::resume): Deleted.
2777         (JSC::MachineThreads::ThreadData::getRegisters): Deleted.
2778         (JSC::MachineThreads::ThreadData::Registers::stackPointer): Deleted.
2779         (JSC::MachineThreads::ThreadData::Registers::framePointer): Deleted.
2780         (JSC::MachineThreads::ThreadData::Registers::instructionPointer): Deleted.
2781         (JSC::MachineThreads::ThreadData::Registers::llintPC): Deleted.
2782         (JSC::MachineThreads::ThreadData::freeRegisters): Deleted.
2783         (JSC::MachineThreads::ThreadData::captureStack): Deleted.
2784         * heap/MachineStackMarker.h:
2785         (JSC::MachineThreads::MachineThread::suspend):
2786         (JSC::MachineThreads::MachineThread::resume):
2787         (JSC::MachineThreads::MachineThread::threadID):
2788         (JSC::MachineThreads::MachineThread::stackBase):
2789         (JSC::MachineThreads::MachineThread::stackEnd):
2790         (JSC::MachineThreads::threadsListHead):
2791         (JSC::MachineThreads::Thread::operator!=): Deleted.
2792         (JSC::MachineThreads::Thread::suspend): Deleted.
2793         (JSC::MachineThreads::Thread::resume): Deleted.
2794         (JSC::MachineThreads::Thread::getRegisters): Deleted.
2795         (JSC::MachineThreads::Thread::freeRegisters): Deleted.
2796         (JSC::MachineThreads::Thread::captureStack): Deleted.
2797         (JSC::MachineThreads::Thread::platformThread): Deleted.
2798         (JSC::MachineThreads::Thread::stackBase): Deleted.
2799         (JSC::MachineThreads::Thread::stackEnd): Deleted.
2800         * jit/ICStats.cpp:
2801         (JSC::ICStats::ICStats):
2802         (JSC::ICStats::~ICStats):
2803         * jit/ICStats.h:
2804         * jsc.cpp:
2805         (functionDollarAgentStart):
2806         (startTimeoutThreadIfNeeded):
2807         * runtime/JSLock.cpp:
2808         (JSC::JSLock::lock):
2809         * runtime/JSLock.h:
2810         (JSC::JSLock::ownerThread):
2811         (JSC::JSLock::currentThreadIsHoldingLock):
2812         * runtime/SamplingProfiler.cpp:
2813         (JSC::FrameWalker::isValidFramePointer):
2814         (JSC::SamplingProfiler::SamplingProfiler):
2815         (JSC::SamplingProfiler::createThreadIfNecessary):
2816         (JSC::SamplingProfiler::takeSample):
2817         * runtime/SamplingProfiler.h:
2818         * runtime/VM.h:
2819         (JSC::VM::ownerThread):
2820         * runtime/VMTraps.cpp:
2821         (JSC::findActiveVMAndStackBounds):
2822         (JSC::VMTraps::SignalSender::send):
2823         (JSC::VMTraps::fireTrap):
2824
2825 2017-04-11  Dean Jackson  <dino@apple.com>
2826
2827         Disable outdated WritableStream API
2828         https://bugs.webkit.org/show_bug.cgi?id=170749
2829         <rdar://problem/31446233>
2830
2831         Reviewed by Tim Horton.
2832
2833         The API we implement is no longer accurate. Disable it until we
2834         are compatible with the new specification
2835
2836         * Configurations/FeatureDefines.xcconfig:
2837
2838 2017-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>
2839
2840         Unreviewed, build fix for CF ports after r215241
2841         https://bugs.webkit.org/show_bug.cgi?id=170725
2842
2843         * heap/GCActivityCallback.cpp:
2844         (JSC::GCActivityCallback::nextFireTime):
2845
2846 2017-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>
2847
2848         [WebCore][JSC] ResourceUsageData.{timeOfNextEdenCollection,timeOfNextFullCollection} should be MonotonicTime
2849         https://bugs.webkit.org/show_bug.cgi?id=170725
2850
2851         Reviewed by Sam Weinig.
2852
2853         This patch makes GCActivityCallback return MonotonicTime instead of raw double value.
2854
2855         * heap/GCActivityCallback.cpp:
2856         (JSC::GCActivityCallback::nextFireTime):
2857         * heap/GCActivityCallback.h:
2858
2859 2017-04-11  Guillaume Emont  <guijemont@igalia.com>
2860
2861         [jsc] Add missing MacroAssemblerMIPS::or32() implementation
2862         https://bugs.webkit.org/show_bug.cgi?id=169714
2863
2864         Reviewed by Michael Catanzaro.
2865
2866         * assembler/MacroAssemblerMIPS.h:
2867         (JSC::MacroAssemblerMIPS::or32):
2868         Added or32(TrustedImm32, Address).
2869
2870 2017-04-11  Joseph Pecoraro  <pecoraro@apple.com>
2871
2872         test262: test262/test/annexB/language/comments/multi-line-html-close.js
2873         https://bugs.webkit.org/show_bug.cgi?id=170648
2874
2875         Reviewed by Keith Miller.
2876
2877         * parser/Lexer.cpp:
2878         (JSC::Lexer<T>::lex):
2879         A multi-line comment that contains a line terminator is itself treated
2880         like a line terminator. An HTML Close Comment that comes after it can
2881         therefore treat it like it is at the start of a line, because it was
2882         immediately preceeded by the equivalent of a line terminator.
2883
2884 2017-04-11  Joseph Pecoraro  <pecoraro@apple.com>
2885
2886         test262: test262/test/built-ins/Array/S15.4.3_A2.2.js
2887         https://bugs.webkit.org/show_bug.cgi?id=170652
2888
2889         Reviewed by Michael Saboff.
2890
2891         * runtime/ArrayConstructor.cpp:
2892         (JSC::ArrayConstructor::finishCreation):
2893         * runtime/BooleanConstructor.cpp:
2894         (JSC::BooleanConstructor::finishCreation):
2895         * runtime/DateConstructor.cpp:
2896         (JSC::DateConstructor::finishCreation):
2897         * runtime/FunctionConstructor.cpp:
2898         (JSC::FunctionConstructor::finishCreation):
2899         * runtime/JSArrayBufferConstructor.cpp:
2900         (JSC::JSArrayBufferConstructor::finishCreation):
2901         * runtime/NumberConstructor.cpp:
2902         (JSC::NumberConstructor::finishCreation):
2903         * runtime/ObjectConstructor.cpp:
2904         (JSC::ObjectConstructor::finishCreation):
2905         * runtime/RegExpConstructor.cpp:
2906         (JSC::RegExpConstructor::finishCreation):
2907         * runtime/StringConstructor.cpp:
2908         (JSC::StringConstructor::finishCreation):
2909         * runtime/SymbolConstructor.cpp:
2910         (JSC::SymbolConstructor::finishCreation):
2911         Ensure the "length" property on these native constructors is configurable (deletable).
2912
2913 2017-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>
2914
2915         Unreviewed, build fix for Windows after r215228 part 2
2916         https://bugs.webkit.org/show_bug.cgi?id=170723
2917
2918         Since GCActivityCallback class is annotated exported, we do not need to annotate each member.
2919
2920         * heap/GCActivityCallback.h:
2921
2922 2017-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>
2923
2924         [JSC][GTK] Use RunLoop::Timer in GTK port
2925         https://bugs.webkit.org/show_bug.cgi?id=170723
2926
2927         Reviewed by Carlos Garcia Campos.
2928
2929         This patch makes GTK port use RunLoop::Timer for JSRunLoopTimer.
2930         Only Cocoa-based ports use platform-specific Timer because it
2931         has additional feature that changes RunLoop to the WebThread one.
2932
2933         And we enable Heap timers in all the ports including JSCOnly port.
2934
2935         * heap/EdenGCActivityCallback.cpp:
2936         (JSC::EdenGCActivityCallback::lastGCLength):
2937         * heap/EdenGCActivityCallback.h:
2938         * heap/FullGCActivityCallback.cpp:
2939         (JSC::FullGCActivityCallback::lastGCLength):
2940         * heap/FullGCActivityCallback.h:
2941         * heap/GCActivityCallback.cpp:
2942         (JSC::GCActivityCallback::GCActivityCallback):
2943         (JSC::GCActivityCallback::doWork):
2944         (JSC::GCActivityCallback::scheduleTimer):
2945         (JSC::GCActivityCallback::cancelTimer):
2946         (JSC::GCActivityCallback::nextFireTime):
2947         (JSC::GCActivityCallback::didAllocate):
2948         * heap/GCActivityCallback.h:
2949         * heap/IncrementalSweeper.cpp:
2950         (JSC::IncrementalSweeper::doWork):
2951         (JSC::IncrementalSweeper::doSweep):
2952         * heap/IncrementalSweeper.h:
2953         * heap/StopIfNecessaryTimer.cpp:
2954         (JSC::StopIfNecessaryTimer::scheduleSoon):
2955         * runtime/JSRunLoopTimer.cpp:
2956         (JSC::JSRunLoopTimer::setRunLoop):
2957         (JSC::JSRunLoopTimer::scheduleTimer):
2958         (JSC::JSRunLoopTimer::cancelTimer):
2959         (JSC::JSRunLoopTimer::JSRunLoopTimer):
2960         (JSC::JSRunLoopTimer::~JSRunLoopTimer):
2961         (JSC::JSRunLoopTimer::timerDidFireCallback):
2962         * runtime/JSRunLoopTimer.h:
2963         * runtime/PromiseDeferredTimer.cpp:
2964         (JSC::PromiseDeferredTimer::scheduleWorkSoon):
2965
2966 2017-04-11  Guillaume Emont  <guijemont@igalia.com>
2967
2968         [jsc][mips] Add missing MacroAssembler functions after r214187
2969         https://bugs.webkit.org/show_bug.cgi?id=170089
2970
2971         Reviewed by Yusuke Suzuki.
2972
2973         * assembler/MacroAssemblerMIPS.h:
2974         (JSC::MacroAssemblerMIPS::loadFloat): Added.
2975         (JSC::MacroAssemblerMIPS::storeFloat): Added.
2976
2977 2017-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>
2978
2979         [JSC] Enable JSRunLoopTimer for JSCOnly and Windows
2980         https://bugs.webkit.org/show_bug.cgi?id=170655
2981
2982         Reviewed by Carlos Garcia Campos.
2983
2984         * runtime/JSRunLoopTimer.cpp:
2985         (JSC::JSRunLoopTimer::JSRunLoopTimer):
2986         (JSC::JSRunLoopTimer::scheduleTimer):
2987         (JSC::JSRunLoopTimer::cancelTimer):
2988         * runtime/JSRunLoopTimer.h:
2989
2990 2017-04-10  Alex Christensen  <achristensen@webkit.org>
2991
2992         Revert r215217
2993         https://bugs.webkit.org/show_bug.cgi?id=170703
2994
2995         * Configurations/FeatureDefines.xcconfig:
2996
2997 2017-04-10  Alex Christensen  <achristensen@webkit.org>
2998
2999         Continue enabling WebRTC
3000         https://bugs.webkit.org/show_bug.cgi?id=170703
3001
3002         Reviewed by Youenn Fablet.
3003
3004         * Configurations/FeatureDefines.xcconfig:
3005
3006 2017-04-10  Mark Lam  <mark.lam@apple.com>
3007
3008         Move ProbeContext and ProbeFunction out of AbstractMacroAssembler.
3009         https://bugs.webkit.org/show_bug.cgi?id=170681
3010
3011         Reviewed by Michael Saboff.
3012
3013         This is a refactoring step towards enabling custom probe printers the way printInternal() works for dataLog.
3014
3015         * assembler/AbstractMacroAssembler.h:
3016         (JSC::AbstractMacroAssembler::ProbeContext::gpr): Deleted.
3017         (JSC::AbstractMacroAssembler::ProbeContext::fpr): Deleted.
3018         (JSC::AbstractMacroAssembler::ProbeContext::gprName): Deleted.
3019         (JSC::AbstractMacroAssembler::ProbeContext::fprName): Deleted.
3020         * assembler/MacroAssembler.cpp:
3021         (JSC::stdFunctionCallback):
3022         (JSC::MacroAssembler::probe):
3023         * assembler/MacroAssembler.h:
3024         (JSC::ProbeContext::gpr):
3025         (JSC::ProbeContext::fpr):
3026         (JSC::ProbeContext::gprName):
3027         (JSC::ProbeContext::fprName):
3028         * assembler/MacroAssemblerARM.cpp:
3029         (JSC::MacroAssemblerARM::probe):
3030         * assembler/MacroAssemblerARM64.cpp:
3031         (JSC::arm64ProbeTrampoline):
3032         (JSC::MacroAssemblerARM64::probe):
3033         * assembler/MacroAssemblerARMv7.cpp:
3034         (JSC::MacroAssemblerARMv7::probe):
3035         * assembler/MacroAssemblerPrinter.cpp:
3036         * assembler/MacroAssemblerPrinter.h:
3037         * assembler/MacroAssemblerX86Common.cpp:
3038         (JSC::MacroAssemblerX86Common::probe):
3039         * ftl/FTLLowerDFGToB3.cpp:
3040         (JSC::FTL::DFG::LowerDFGToB3::abstractStructure):
3041         (JSC::FTL::DFG::LowerDFGToB3::probe): Deleted.
3042         - Deleted because this became a useless place-holder after the transition to B3.
3043
3044 2017-04-10  Keith Miller  <keith_miller@apple.com>
3045
3046         WebAssembly: Fix B3IRGenerator for BrTable
3047         https://bugs.webkit.org/show_bug.cgi?id=170685
3048
3049         Reviewed by JF Bastien.
3050
3051         For some reason this didn't get included in r215141.
3052
3053         This fixes an issue with BrTable and loops where we would use the loop's return type
3054         as the branch target type.
3055
3056         * wasm/WasmB3IRGenerator.cpp:
3057         (JSC::Wasm::B3IRGenerator::ControlData::resultForBranch):
3058         (JSC::Wasm::B3IRGenerator::unifyValuesWithBlock):
3059
3060 2017-04-08  Oliver Hunt  <oliver@apple.com>
3061
3062         Remove use of strcpy from JSC
3063         https://bugs.webkit.org/show_bug.cgi?id=170646
3064
3065         Reviewed by Mark Lam.
3066
3067         Replace the use of strcpy with memcpy as strcpy keeps
3068         on tripping various analyser warnings even though its
3069         trivially safe in this case.
3070
3071         Essentially code hygiene, no change in behaviour, no
3072         perf impact.
3073
3074         * dfg/DFGDisassembler.cpp:
3075         (JSC::DFG::Disassembler::dumpDisassembly):
3076
3077 2017-04-09  Joseph Pecoraro  <pecoraro@apple.com>
3078
3079         test262: test262/test/annexB/language/expressions/object/__proto__-fn-name.js
3080         https://bugs.webkit.org/show_bug.cgi?id=170650
3081
3082         Reviewed by Saam Barati.
3083
3084         * parser/Parser.cpp:
3085         (JSC::Parser<LexerType>::parseClass):
3086         (JSC::Parser<LexerType>::parseProperty):
3087         There needs to be special handling of:
3088         
3089           PropertyDefinition :  PropertyName ':' AssignmentExpression
3090          
3091         When the property name is __proto__. In this case the
3092         SetFunctionName path does not happen, so the name "__proto__"
3093         is not inferred on any anonymous function. See:
3094         https://tc39.github.io/ecma262/#sec-__proto__-property-names-in-object-initializers
3095
3096         * parser/Parser.h:
3097         * parser/SyntaxChecker.h:
3098         (JSC::SyntaxChecker::createProperty):
3099         * parser/ASTBuilder.h:
3100         (JSC::ASTBuilder::createProperty):
3101         Add an extra parameter to see if inferring / setting names are allowed.
3102
3103 2017-04-09  Joseph Pecoraro  <pecoraro@apple.com>
3104
3105         test262: test262/test/annexB/language/literals/regexp/identity-escape.js
3106         https://bugs.webkit.org/show_bug.cgi?id=170651
3107
3108         Reviewed by Saam Barati.
3109
3110         * yarr/YarrParser.h:
3111         (JSC::Yarr::Parser::parseEscape):
3112         For \8 and \9 match just the number "8" or "9" instead of both "\\" and the number.
3113         See: https://tc39.github.io/ecma262/#sec-decimalescape
3114
3115 2017-04-08  Youenn Fablet  <youenn@apple.com>
3116
3117         WebRTC tests gardening
3118         https://bugs.webkit.org/show_bug.cgi?id=170508
3119
3120         Reviewed by Eric Carlson.
3121
3122         * Configurations/FeatureDefines.xcconfig:
3123
3124 2017-04-07  Keith Miller  <keith_miller@apple.com>
3125
3126         WebAssembly: Fix issue with BrTable targeting a Loop
3127         https://bugs.webkit.org/show_bug.cgi?id=170638
3128
3129         Reviewed by Saam Barati.
3130
3131         This fixes the same issue V8 had in: https://github.com/WebAssembly/spec/pull/456#event-1033547537
3132
3133         * wasm/WasmValidate.cpp:
3134         (JSC::Wasm::Validate::ControlData::branchTargetSignature):
3135
3136 2017-04-07  Keith Miller  <keith_miller@apple.com>
3137
3138         Add a PriorityQueue class
3139         https://bugs.webkit.org/show_bug.cgi?id=170579
3140
3141         Reviewed by Saam Barati.
3142
3143         Update Wasm::Worklist to use WTF::PriorityQueue.
3144
3145         * wasm/WasmWorklist.cpp:
3146         (JSC::Wasm::Worklist::enqueue):
3147         (JSC::Wasm::Worklist::completePlanSynchronously):
3148         (JSC::Wasm::Worklist::stopAllPlansForVM):
3149         (JSC::Wasm::Worklist::~Worklist):
3150         (JSC::Wasm::Worklist::iterate): Deleted.
3151         * wasm/WasmWorklist.h:
3152         (JSC::Wasm::Worklist::isHigherPriority):
3153         (JSC::Wasm::Worklist::Comparator::operator()): Deleted.
3154
3155 2017-04-07  Yuichiro Kikura  <y.kikura@gmail.com>
3156
3157         WebGPU: implement ComputeCommandEncoder and related components
3158         https://bugs.webkit.org/show_bug.cgi?id=170444
3159
3160         Reviewed by Alex Christensen.
3161
3162         I added some identifiers related with WebGPUComputeCommandEncoder based on the proposal.
3163         https://webkit.org/wp-content/uploads/webgpu-api-proposal.html
3164
3165         * runtime/CommonIdentifiers.h:
3166
3167 2017-04-07  Saam Barati  <sbarati@apple.com>
3168
3169         WebAssembly: Module::getOrCreateCodeBlock is wrong
3170         https://bugs.webkit.org/show_bug.cgi?id=170612
3171
3172         Reviewed by Keith Miller.
3173
3174         When we were getting a module's CodeBlock, we were checking if !runnable(),
3175         and if !runnable(), we were re-creating the CodeBlock. This is wrong, since
3176         !runnable() is true while the CodeBlock is compiling. Instead, we should check
3177         if we've finished compiling, and if so, if that compilation failed.
3178
3179         * wasm/WasmModule.cpp:
3180         (JSC::Wasm::Module::getOrCreateCodeBlock):
3181
3182 2017-04-07  Saam Barati  <sbarati@apple.com>
3183
3184         WebAssembly: Make to a compilation API that allows for multi-VM concurrent compilations of Wasm Modules
3185         https://bugs.webkit.org/show_bug.cgi?id=170488
3186
3187         Reviewed by JF Bastien.
3188
3189         This patch adds a class called Wasm::Module. It contains the bits from
3190         JSWebAssemblyModule that were not VM specific. JSWebAssemblyModule
3191         now has a Ref<Wasm::Module>. Similarly, there is now a Wasm::CodeBlock,
3192         which owns the non-VM-specific bits that JSWebAssemblyCodeBlock used
3193         to own.
3194         
3195         This patch also simplifies how we verify and compile code. Wasm::Module
3196         now has an API for both sync/async validation and compilation. This
3197         API abstracts away how Wasm::Plan works.
3198         
3199         This is hopefully the last patch needed before we can implement
3200         window.postMessage for a JSWebAssemblyModule. I think all that's
3201         needed now to implement postMessage is simply creating a new
3202         JSWebAssemblyModule with the underlying Wasm::Module.
3203         
3204         This patch is neutral on WasmBench.
3205         
3206         Finally, this patch changes the promise deferred timer to
3207         allow for new tasks to be added while we're executing
3208         a task. Before, we'd deadlock if this happened.
3209
3210         * CMakeLists.txt:
3211         * JavaScriptCore.xcodeproj/project.pbxproj:
3212         * jsc.cpp:
3213         (functionTestWasmModuleFunctions):
3214         * runtime/PromiseDeferredTimer.cpp:
3215         (JSC::PromiseDeferredTimer::doWork):
3216         (JSC::PromiseDeferredTimer::scheduleWorkSoon):
3217         * runtime/PromiseDeferredTimer.h:
3218         * wasm/WasmB3IRGenerator.cpp:
3219         * wasm/WasmBinding.cpp:
3220         (JSC::Wasm::wasmToJs):
3221         (JSC::Wasm::wasmToWasm):
3222         (JSC::Wasm::exitStubGenerator): Deleted.
3223         * wasm/WasmBinding.h:
3224         * wasm/WasmCodeBlock.cpp: Added.
3225         (JSC::Wasm::CodeBlock::CodeBlock):
3226         (JSC::Wasm::CodeBlock::waitUntilFinished):
3227         (JSC::Wasm::CodeBlock::compileAsync):
3228         (JSC::Wasm::CodeBlock::isSafeToRun):
3229         * wasm/WasmCodeBlock.h: Added.
3230         (JSC::Wasm::CodeBlock::create):
3231         (JSC::Wasm::CodeBlock::compilationFinished):
3232         (JSC::Wasm::CodeBlock::runnable):
3233         (JSC::Wasm::CodeBlock::errorMessage):
3234         (JSC::Wasm::CodeBlock::functionImportCount):
3235         (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
3236         (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
3237         * wasm/WasmModule.cpp: Added.
3238         (JSC::Wasm::Module::Module):
3239         (JSC::Wasm::makeValidationResult):
3240         (JSC::Wasm::Module::validateSyncImpl):
3241         (JSC::Wasm::Module::getOrCreateCodeBlock):
3242         (JSC::Wasm::Module::compileSync):
3243         (JSC::Wasm::Module::makeValidationCallback):
3244         (JSC::Wasm::Module::compileAsync):
3245         * wasm/WasmModule.h: Added.
3246         (JSC::Wasm::Module::create):
3247         (JSC::Wasm::Module::validateSync):
3248         (JSC::Wasm::Module::validateAsync):
3249         (JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace):
3250         (JSC::Wasm::Module::moduleInformation):
3251         (JSC::Wasm::Module::nonNullCodeBlock):
3252         * wasm/WasmPlan.cpp:
3253         (JSC::Wasm::Plan::Plan):
3254         (JSC::Wasm::Plan::addCompletionTask):
3255         (JSC::Wasm::Plan::prepare):
3256         (JSC::Wasm::Plan::compileFunctions):
3257         (JSC::Wasm::Plan::complete):
3258         (JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast):
3259         (JSC::Wasm::Plan::cancel): Deleted.
3260         * wasm/WasmPlan.h:
3261         (JSC::Wasm::Plan::dontFinalize):
3262         (JSC::Wasm::Plan::takeWasmToWasmExitStubs):
3263         (JSC::Wasm::Plan::mode):
3264         (JSC::Wasm::Plan::takeWasmExitStubs): Deleted.
3265         (JSC::Wasm::Plan::vm): Deleted.
3266         * wasm/WasmWorklist.cpp:
3267         (JSC::Wasm::Worklist::stopAllPlansForVM):
3268         * wasm/js/JSWebAssemblyCodeBlock.cpp:
3269         (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
3270         (JSC::JSWebAssemblyCodeBlock::isSafeToRun):
3271         (JSC::JSWebAssemblyCodeBlock::initialize): Deleted.
3272         * wasm/js/JSWebAssemblyCodeBlock.h:
3273         (JSC::JSWebAssemblyCodeBlock::create):
3274         (JSC::JSWebAssemblyCodeBlock::functionImportCount):
3275         (JSC::JSWebAssemblyCodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
3276         (JSC::JSWebAssemblyCodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
3277         (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport):
3278         (JSC::JSWebAssemblyCodeBlock::mode): Deleted.
3279         (JSC::JSWebAssemblyCodeBlock::initialized): Deleted.
3280         (JSC::JSWebAssemblyCodeBlock::plan): Deleted.
3281         (JSC::JSWebAssemblyCodeBlock::runnable): Deleted.
3282         (JSC::JSWebAssemblyCodeBlock::errorMessage): Deleted.
3283         (JSC::JSWebAssemblyCodeBlock::setJSEntrypointCallee): Deleted.
3284         (JSC::JSWebAssemblyCodeBlock::setWasmEntrypointCallee): Deleted.
3285         * wasm/js/JSWebAssemblyInstance.cpp:
3286         (JSC::JSWebAssemblyInstance::finalizeCreation):
3287         (JSC::JSWebAssemblyInstance::addUnitializedCodeBlock): Deleted.
3288         * wasm/js/JSWebAssemblyInstance.h:
3289         (JSC::JSWebAssemblyInstance::initialized): Deleted.
3290         * wasm/js/JSWebAssemblyModule.cpp:
3291         (JSC::JSWebAssemblyModule::createStub):
3292         (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
3293         (JSC::JSWebAssemblyModule::finishCreation):
3294         * wasm/js/JSWebAssemblyModule.h:
3295         (JSC::JSWebAssemblyModule::moduleInformation):
3296         (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace):
3297         (JSC::JSWebAssemblyModule::module):
3298         * wasm/js/WebAssemblyFunction.cpp:
3299         (JSC::WebAssemblyFunction::create):
3300         * wasm/js/WebAssemblyInstanceConstructor.cpp:
3301         (JSC::constructJSWebAssemblyInstance):
3302         * wasm/js/WebAssemblyModuleConstructor.cpp:
3303         (JSC::WebAssemblyModuleConstructor::createModule):
3304         * wasm/js/WebAssemblyPrototype.cpp:
3305         (JSC::reject):
3306         (JSC::webAssemblyCompileFunc):
3307         (JSC::resolve):
3308         (JSC::instantiate):
3309         (JSC::compileAndInstantiate):
3310         (JSC::webAssemblyValidateFunc):
3311
3312 2017-04-07  Carlos Garcia Campos  <cgarcia@igalia.com>
3313
3314         [GTK] Update the priorities used in glib main loop sources
3315         https://bugs.webkit.org/show_bug.cgi?id=170457
3316
3317         Reviewed by Žan Doberšek.
3318
3319         * runtime/JSRunLoopTimer.cpp:
3320         (JSC::JSRunLoopTimer::JSRunLoopTimer):
3321
3322 2017-04-06  Filip Pizlo  <fpizlo@apple.com>
3323
3324         Rename allocateStack to allocateStackByGraphColoring.
3325
3326         Rubber stamped by Saam Barati.
3327
3328         * CMakeLists.txt:
3329         * JavaScriptCore.xcodeproj/project.pbxproj:
3330         * b3/air/AirAllocateStack.cpp: Removed.
3331         * b3/air/AirAllocateStack.h: Removed.
3332         * b3/air/AirAllocateStackByGraphColoring.cpp: Copied from Source/JavaScriptCore/b3/air/AirAllocateStack.cpp.
3333         (JSC::B3::Air::allocateStackByGraphColoring):
3334         (JSC::B3::Air::allocateStack): Deleted.
3335         * b3/air/AirAllocateStackByGraphColoring.h: Copied from Source/JavaScriptCore/b3/air/AirAllocateStack.h.
3336         * b3/air/AirGenerate.cpp:
3337         (JSC::B3::Air::prepareForGeneration):
3338
3339 2017-04-06  Michael Saboff  <msaboff@apple.com>
3340
3341         Cannot Object.seal() or Object.freeze() global "this"
3342         https://bugs.webkit.org/show_bug.cgi?id=170549
3343
3344         Reviewed by Mark Lam.
3345
3346         Needed to implement JSProxy::isExtensible() which returns the results of calling
3347         the same on wrapped object.
3348
3349         Implemented step 11 of Runtime Semantics: EvalDeclarationInstantiation from the ECMAScript
3350         spec to properly return a TypeError object when attempting to add properties to a
3351         non-extensible global object.
3352
3353         * interpreter/Interpreter.cpp:
3354         (JSC::Interpreter::execute):
3355         * runtime/JSProxy.cpp:
3356         (JSC::JSProxy::isExtensible):
3357         * runtime/JSProxy.h:
3358
3359 2017-04-06  Filip Pizlo  <fpizlo@apple.com>
3360
3361         Linear scan should run liveness only once
3362         https://bugs.webkit.org/show_bug.cgi?id=170569
3363
3364         Reviewed by Keith Miller.
3365         
3366         Air has a longstanding design bug that Tmps from different banks are indexed independently. This
3367         means that all of our analyses over Tmps do separate GP and FP passes. This does have some
3368         marginal benefits (the rest of the algorithm is specialized for Bank) but it's probably net bad.
3369         However, I don't want to think about solving that general problem.
3370         
3371         Instead, this just makes linear scan use a UnifiedTmpLiveness that uses a single "linear"
3372         indexing for GP and FP. This lets me avoid the much larger refactoring (which would involve
3373         substantial changes in graph coloring) while getting the bulk of the benefit (liveness runs once,
3374         instead of twice, for linear scan).
3375         
3376         This patch implements a lot of plumbing to make it possible for Liveness<> to view Tmps as having
3377         a unified indexing scheme. Tmp calls this LinearlyIndexed (to match the naming convention of
3378         AbsolutelyIndexed and Indexed), while AirLiveness calls this UnifiedTmpLiveness. With this
3379         change, -O1 never does any liveness analysis that uses separate GP and FP passes. I think this
3380         eliminates any urgency from the larger Tmp indexing bug. We can probably live with graph coloring
3381         doing separate passes.
3382         
3383         This is a ~6% speed-up for wasm -O1 compile times. I think this means that linear scan is no
3384         longer the longest pole in the tent.
3385
3386         * JavaScriptCore.xcodeproj/pr