new super should be a syntax error
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-05-04  Ryosuke Niwa  <rniwa@webkit.org>
2
3         new super should be a syntax error
4         https://bugs.webkit.org/show_bug.cgi?id=144282
5
6         Reviewed by Joseph Pecoraro.
7
8         Disallow "new super" as ES6 spec doesn't allow this.
9
10         * parser/Parser.cpp:
11         (JSC::Parser<LexerType>::parseMemberExpression):
12
13 2015-05-04  Saam Barati  <saambarati1@gmail.com>
14
15         JSCallbackObject does not maintain symmetry between accesses for getOwnPropertySlot and put
16         https://bugs.webkit.org/show_bug.cgi?id=144265
17
18         Reviewed by Geoffrey Garen.
19
20         JSCallbackObject will defer to a parent's implementation of getOwnPropertySlot
21         for a static function if the parent has that property slot. JSCallbackObject::put 
22         did not maintain this symmetry of also calling ::put on the parent if the parent 
23         has the property. We should ensure that this symmetry exists.
24
25         * API/JSCallbackObjectFunctions.h:
26         (JSC::JSCallbackObject<Parent>::put):
27         * API/tests/testapi.c:
28         * API/tests/testapi.js:
29         (globalStaticFunction2):
30         (this.globalStaticFunction2):
31         (iAmNotAStaticFunction):
32         (this.iAmNotAStaticFunction):
33
34 2015-05-04  Andreas Kling  <akling@apple.com>
35
36         Make ExecState::vm() branchless in release builds.
37         <https://webkit.org/b/144586>
38
39         Reviewed by Geoffrey Garen.
40
41         Avoid null checking the ExecState's callee() before getting the
42         VM from it. The code was already dereferencing it anyway, since we
43         know it's not gonna be null.
44
45         * runtime/JSCellInlines.h:
46         (JSC::ExecState::vm):
47
48 2015-05-04  Basile Clement  <basile_clement@apple.com>
49
50         Object allocation not sinking properly through CheckStructure
51         https://bugs.webkit.org/show_bug.cgi?id=144465
52
53         Reviewed by Filip Pizlo.
54
55         Currently, sinking an allocation through a CheckStructure will
56         completely ignore all structure checking, which is obviously wrong.
57
58         A CheckStructureImmediate node type was present for that purpose, but
59         the CheckStructures were not properly replaced.  This ensures that
60         CheckStructure nodes are replaced by CheckStructureImmediate nodes when
61         sunk through, and that structure checking happens correctly.
62
63         * dfg/DFGNode.h:
64         (JSC::DFG::Node::convertToCheckStructureImmediate): Added.
65         (JSC::DFG::Node::hasStructureSet):
66         * dfg/DFGObjectAllocationSinkingPhase.cpp:
67         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
68         * ftl/FTLLowerDFGToLLVM.cpp:
69         (JSC::FTL::LowerDFGToLLVM::compileCheckStructure):
70         (JSC::FTL::LowerDFGToLLVM::compileCheckStructureImmediate):
71         (JSC::FTL::LowerDFGToLLVM::checkStructure):
72         * tests/stress/sink_checkstructure.js: Added.
73         (foo):
74
75 2015-05-01  Geoffrey Garen  <ggaren@apple.com>
76
77         REGRESSION(r183570): jslib-traverse-jquery is 22% slower
78         https://bugs.webkit.org/show_bug.cgi?id=144476
79
80         Reviewed by Sam Weinig.
81
82         jslib-traverse-jquery is now 31% faster than its unregressed baseline.
83
84         The jQuery algorithm for sorting DOM nodes is so pathologically slow that,
85         to my knowledge, the topic of how to optimize it is not covered in any
86         literature about sorting.
87
88         On the slowest jQuery sorting test -- prevAll -- our new
89         Array.prototype.sort, compared to its predecessor, performed 12% fewer
90         comparisons and requireed 10X less overhead per comparison. Yet, it was
91         slower.
92
93         It was slower because it inadvertantly increased the average cost of the
94         comparison function by 2X. jQuery uses compareDocumentPosition to compare
95         DOM nodes, and compareDocumentPosition(a, b) is O(N) in the distance
96         required to traverse backwards from b to a. In prevAll, we encounter the
97         worst case for merge sort of compareDocumentPosition: A long list of DOM
98         nodes in mostly reverse order. In this case, merge sort will sequentially
99         compareDocumentPosition(a, b), where a is not reachable backwards from
100         b, and therefore compareDocumentPosition will traverse the whole sibling
101         list.
102
103         The solution is simple enough: Call compareDocumentPosition(b, a) instead.
104
105         This is a pretty silly thing to do, but it is harmless, and jQuery is
106         popular, so let's do it.
107
108         We do not risk suffering the same problem in reverse when sorting a long
109         list of DOM nodes in forward order. (We still have a 37% speedup on the
110         nextAll benchmark.) The reason is that merge sort performs 2X fewer
111         comparisons when the list is already sorted, so we can worry less about
112         the cost of each comparison.
113
114         A fully principled soultion to this problem would probably do something
115         like Python's timsort, which special-cases ordered ranges to perform
116         only O(n) comparisons. But that would contradict our original
117         goal of just having something simple that works.
118
119         Another option is for elements to keep a compareDocumentPosition cache,
120         like a node list cache, which allows you to determine the absolute
121         position of a node using a hash lookup. I will leave this as an exercise
122         for kling.
123
124         * builtins/Array.prototype.js:
125         (sort.merge): Compare in an order that is favorable to a comparator
126         that calls compareDocumentPosition.
127
128 2015-05-04  Csaba Osztrogonác  <ossy@webkit.org>
129
130         [cmake] Fix generate-js-builtins related incremental build issue
131         https://bugs.webkit.org/show_bug.cgi?id=144094
132
133         Reviewed by Michael Saboff.
134
135         * CMakeLists.txt: Generated JSCBuiltins.<cpp|h> should depend on Source/JavaScriptCore/builtins directory.
136         Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
137         * DerivedSources.make:
138         Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
139         * generate-js-builtins: Accept input files and input directory too.
140
141 2015-05-03  Simon Fraser  <simon.fraser@apple.com>
142
143         Make some static data const
144         https://bugs.webkit.org/show_bug.cgi?id=144552
145
146         Reviewed by Andreas Kling.
147         
148         Turn characterSetInfo into const data.
149
150         * yarr/YarrCanonicalizeUCS2.cpp:
151         * yarr/YarrCanonicalizeUCS2.h:
152
153 2015-05-01  Filip Pizlo  <fpizlo@apple.com>
154
155         TypeOf should be fast
156         https://bugs.webkit.org/show_bug.cgi?id=144396
157
158         Reviewed by Geoffrey Garen.
159         
160         Adds comprehensive support for fast typeof to the optimizing JITs. Calls into the runtime
161         are only used for very exotic objects - they must have either the MasqueradesAsUndefined or
162         TypeOfShouldCallGetCallData type flags set. All other cases are handled inline.
163         
164         This means optimizing IsObjectOrNull, IsFunction, and TypeOf - all node types that used to
165         rely heavily on C++ calls to fulfill their function.
166         
167         Because TypeOf is now so fast, we no longer need to do any speculations on this node.
168         
169         In the FTL, we take this further by querying AI for each branch in the TypeOf decision tree.
170         This means that if the TypeOf is dominated by any type checks, we will automatically prune
171         out cases that are redundant.
172         
173         This patch anticipates the addition of SwitchTypeOf or something like that. So, the TypeOf
174         code generation is designed to be reusable.
175         
176         This is a speed-up on most typeof benchmarks. But, it is a slow-down on benchmarks that take
177         the exotic call trap hook. That hook is now in a deeper slow path than before.
178
179         * CMakeLists.txt:
180         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
181         * JavaScriptCore.xcodeproj/project.pbxproj:
182         * dfg/DFGClobberize.h:
183         (JSC::DFG::clobberize): TypeOf was pure all along, but we failed to realize this.
184         * dfg/DFGFixupPhase.cpp:
185         (JSC::DFG::FixupPhase::fixupNode):
186         * dfg/DFGHeapLocation.cpp:
187         (WTF::printInternal):
188         * dfg/DFGHeapLocation.h:
189         * dfg/DFGOperations.cpp:
190         * dfg/DFGOperations.h:
191         * dfg/DFGSpeculativeJIT.cpp:
192         (JSC::DFG::SpeculativeJIT::compileIsObjectOrNull):
193         (JSC::DFG::SpeculativeJIT::compileIsFunction):
194         (JSC::DFG::SpeculativeJIT::compileTypeOf):
195         * dfg/DFGSpeculativeJIT.h:
196         (JSC::DFG::SpeculativeJIT::blessedBooleanResult):
197         (JSC::DFG::SpeculativeJIT::callOperation):
198         * dfg/DFGSpeculativeJIT32_64.cpp:
199         (JSC::DFG::SpeculativeJIT::compile):
200         * dfg/DFGSpeculativeJIT64.cpp:
201         (JSC::DFG::SpeculativeJIT::compile):
202         * ftl/FTLCapabilities.cpp:
203         (JSC::FTL::canCompile):
204         * ftl/FTLIntrinsicRepository.h:
205         * ftl/FTLLowerDFGToLLVM.cpp:
206         (JSC::FTL::LowerDFGToLLVM::compileNode):
207         (JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
208         (JSC::FTL::LowerDFGToLLVM::compileIsFunction):
209         (JSC::FTL::LowerDFGToLLVM::compileTypeOf):
210         (JSC::FTL::LowerDFGToLLVM::buildTypeOf): Reusable TypeOf building for the FTL.
211         (JSC::FTL::LowerDFGToLLVM::isExoticForTypeof):
212         * ftl/FTLSwitchCase.h:
213         (JSC::FTL::SwitchCase::SwitchCase):
214         * jit/AssemblyHelpers.h:
215         (JSC::AssemblyHelpers::branchIfNotEqual):
216         (JSC::AssemblyHelpers::branchIfEqual):
217         (JSC::AssemblyHelpers::branchIfNumber):
218         (JSC::AssemblyHelpers::branchIfNotNumber):
219         (JSC::AssemblyHelpers::branchIfBoolean):
220         (JSC::AssemblyHelpers::branchIfNotBoolean):
221         (JSC::AssemblyHelpers::boxBooleanPayload):
222         (JSC::AssemblyHelpers::boxBoolean):
223         (JSC::AssemblyHelpers::emitTypeOf): Reusable TypeOf building for assembly JITs.
224         * jit/JITOperations.h:
225         * runtime/SmallStrings.h:
226         (JSC::SmallStrings::typeString):
227         * runtime/TypeofType.cpp: Added.
228         (WTF::printInternal):
229         * runtime/TypeofType.h: Added.
230         * tests/stress/type-of-functions-and-objects.js: Modified this test to give more comprehensive feedback.
231
232 2015-05-02  Filip Pizlo  <fpizlo@apple.com>
233
234         Unreviewed, add a FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=144527.
235
236         * dfg/DFGLICMPhase.cpp:
237         (JSC::DFG::LICMPhase::attemptHoist):
238
239 2015-05-02  Filip Pizlo  <fpizlo@apple.com>
240
241         Unreviewed, add FIXMEs referencing https://bugs.webkit.org/show_bug.cgi?id=144524 and
242         https://bugs.webkit.org/show_bug.cgi?id=144525.
243
244         * dfg/DFGLICMPhase.cpp:
245         (JSC::DFG::LICMPhase::attemptHoist):
246         * dfg/DFGPhantomInsertionPhase.cpp:
247
248 2015-05-02  Yusuke Suzuki  <utatane.tea@gmail.com>
249
250         Static property hashtable should only lookup with non-symbol key
251         https://bugs.webkit.org/show_bug.cgi?id=144438
252
253         Reviewed by Darin Adler.
254
255         Static property hashtable compares the Identifier's uid
256         with the normal C string without interning it.
257         So this comparison is performed in their contents.
258         As the result, in this comparison, symbol-ness is not considered.
259
260         So if accidentally the hash collision occur with the symbol and the string
261         and they have the same contents, the hash table entry is looked up incorrectly.
262
263         * runtime/Lookup.h:
264         (JSC::HashTable::entry):
265
266 2015-05-01  Ryosuke Niwa  <rniwa@webkit.org>
267
268         Class syntax should allow string and numeric identifiers for method names
269         https://bugs.webkit.org/show_bug.cgi?id=144254
270
271         Reviewed by Darin Adler.
272
273         Added the support for string and numeric identifiers in class syntax.
274
275         * parser/Parser.cpp:
276         (JSC::Parser<LexerType>::parseFunctionInfo): Instead of using ConstructorKind to indicate whether we're
277         inside a class or not, use the newly added SuperBinding argument instead. ConstructorKind is now None
278         outside a class constructor as it should be.
279         (JSC::Parser<LexerType>::parseFunctionDeclaration):
280         (JSC::Parser<LexerType>::parseClass): No longer expects an identifier at the beginning of every class
281         element to allow numeric and string method names. For both of those method names, parse it here instead
282         of parseFunctionInfo since it doesn't support either type. Also pass in SuperBinding::Needed.
283         (JSC::Parser<LexerType>::parsePropertyMethod): Call parseFunctionInfo with SuperBinding::NotNeeded since
284         this function is never used to parse a class method.
285         (JSC::Parser<LexerType>::parseGetterSetter): Pass in superBinding argument to parseFunctionInfo.
286         (JSC::Parser<LexerType>::parsePrimaryExpression): Call parseFunctionInfo with SuperBinding::NotNeeded.
287         * parser/Parser.h:
288         * parser/SyntaxChecker.h:
289         (JSC::SyntaxChecker::createProperty):
290
291 2015-05-01  Filip Pizlo  <fpizlo@apple.com>
292
293         FTL should use AI more
294         https://bugs.webkit.org/show_bug.cgi?id=144500
295
296         Reviewed by Oliver Hunt.
297         
298         This makes our type check folding even more comprehensive by ensuring that even if the FTL
299         decides to emit some checks, it will still do another query to the abstract interpreter to
300         see if the check is necessary. This helps with cases where we decided early on to speculate
301         one way, but later proved a more specific type of the value in question, and the constant
302         folder didn't catch it.
303         
304         This also makes it more natural to query the abstract interpreter. For example, if you just
305         want the proven type, you can now say provenType(node) or provenType(edge).
306
307         * dfg/DFGArrayMode.cpp:
308         (JSC::DFG::ArrayMode::alreadyChecked):
309         * dfg/DFGArrayMode.h:
310         * ftl/FTLLowerDFGToLLVM.cpp:
311         (JSC::FTL::LowerDFGToLLVM::compileBooleanToNumber):
312         (JSC::FTL::LowerDFGToLLVM::compileToThis):
313         (JSC::FTL::LowerDFGToLLVM::compileValueAdd):
314         (JSC::FTL::LowerDFGToLLVM::compileArithAddOrSub):
315         (JSC::FTL::LowerDFGToLLVM::compileArithPow):
316         (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
317         (JSC::FTL::LowerDFGToLLVM::compileGetById):
318         (JSC::FTL::LowerDFGToLLVM::compileCheckArray):
319         (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
320         (JSC::FTL::LowerDFGToLLVM::compileToStringOrCallStringConstructor):
321         (JSC::FTL::LowerDFGToLLVM::compileToPrimitive):
322         (JSC::FTL::LowerDFGToLLVM::compileStringCharAt):
323         (JSC::FTL::LowerDFGToLLVM::compileStringCharCodeAt):
324         (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
325         (JSC::FTL::LowerDFGToLLVM::compileSwitch):
326         (JSC::FTL::LowerDFGToLLVM::compileIsBoolean):
327         (JSC::FTL::LowerDFGToLLVM::compileIsNumber):
328         (JSC::FTL::LowerDFGToLLVM::compileIsString):
329         (JSC::FTL::LowerDFGToLLVM::compileIsObject):
330         (JSC::FTL::LowerDFGToLLVM::compileInstanceOf):
331         (JSC::FTL::LowerDFGToLLVM::numberOrNotCellToInt32):
332         (JSC::FTL::LowerDFGToLLVM::baseIndex):
333         (JSC::FTL::LowerDFGToLLVM::compareEqObjectOrOtherToObject):
334         (JSC::FTL::LowerDFGToLLVM::typedArrayLength):
335         (JSC::FTL::LowerDFGToLLVM::boolify):
336         (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
337         (JSC::FTL::LowerDFGToLLVM::lowInt32):
338         (JSC::FTL::LowerDFGToLLVM::lowInt52):
339         (JSC::FTL::LowerDFGToLLVM::lowCell):
340         (JSC::FTL::LowerDFGToLLVM::lowBoolean):
341         (JSC::FTL::LowerDFGToLLVM::lowDouble):
342         (JSC::FTL::LowerDFGToLLVM::isCellOrMisc):
343         (JSC::FTL::LowerDFGToLLVM::isNotCellOrMisc):
344         (JSC::FTL::LowerDFGToLLVM::isNumber):
345         (JSC::FTL::LowerDFGToLLVM::isNotNumber):
346         (JSC::FTL::LowerDFGToLLVM::isNotCell):
347         (JSC::FTL::LowerDFGToLLVM::isCell):
348         (JSC::FTL::LowerDFGToLLVM::isNotMisc):
349         (JSC::FTL::LowerDFGToLLVM::isMisc):
350         (JSC::FTL::LowerDFGToLLVM::isNotBoolean):
351         (JSC::FTL::LowerDFGToLLVM::isBoolean):
352         (JSC::FTL::LowerDFGToLLVM::isNotOther):
353         (JSC::FTL::LowerDFGToLLVM::isOther):
354         (JSC::FTL::LowerDFGToLLVM::isProvenValue):
355         (JSC::FTL::LowerDFGToLLVM::isObject):
356         (JSC::FTL::LowerDFGToLLVM::isNotObject):
357         (JSC::FTL::LowerDFGToLLVM::isNotString):
358         (JSC::FTL::LowerDFGToLLVM::isString):
359         (JSC::FTL::LowerDFGToLLVM::isFunction):
360         (JSC::FTL::LowerDFGToLLVM::isNotFunction):
361         (JSC::FTL::LowerDFGToLLVM::speculateObjectOrOther):
362         (JSC::FTL::LowerDFGToLLVM::speculateStringObjectForStructureID):
363         (JSC::FTL::LowerDFGToLLVM::speculateNotStringVar):
364         (JSC::FTL::LowerDFGToLLVM::abstractValue):
365         (JSC::FTL::LowerDFGToLLVM::provenType):
366         (JSC::FTL::LowerDFGToLLVM::provenValue):
367         (JSC::FTL::LowerDFGToLLVM::abstractStructure):
368
369 2015-05-01  Martin Robinson  <mrobinson@igalia.com>
370
371         USE(...) macro should expect unprefixed variables
372         https://bugs.webkit.org/show_bug.cgi?id=144454
373
374         Reviewed by Daniel Bates.
375
376         * CMakeLists.txt: Replace all occurrences WTF_USE with USE.
377
378 2015-05-01  Jordan Harband  <ljharb@gmail.com>
379
380         String#startsWith/endsWith/includes don't handle Infinity position/endPosition args correctly
381         https://bugs.webkit.org/show_bug.cgi?id=144314
382
383         Reviewed by Darin Adler.
384
385         Fixing handling of Infinity position args, per
386         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.includes
387         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.startswith
388         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.endswith
389
390         * runtime/StringPrototype.cpp:
391         (JSC::clampInt32):
392         (JSC::stringProtoFuncStartsWith):
393         (JSC::stringProtoFuncEndsWith):
394         (JSC::stringProtoFuncIncludes):
395
396 2015-05-01  Basile Clement  <basile_clement@apple.com>
397
398         Math.abs() returns negative
399         https://bugs.webkit.org/show_bug.cgi?id=137827
400
401         Reviewed by Michael Saboff.
402
403         Math.abs() on doubles was mistakenly assumed by the DFG AI to be the
404         identity function.
405
406         * dfg/DFGAbstractInterpreterInlines.h:
407         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
408         * tests/stress/math-abs-positive.js: Added, was previously failing.
409         (foo):
410
411 2015-05-01  Basile Clement  <basile_clement@apple.com>
412
413         Function allocation sinking shouldn't be performed on singleton functions
414         https://bugs.webkit.org/show_bug.cgi?id=144166
415
416         Reviewed by Geoffrey Garen.
417
418         Function allocations usually are free of any other side effects, but
419         this is not the case for allocations performed while the underlying
420         FunctionExecutable is still a singleton (as this allogation will fire
421         watchpoints invalidating code that depends on it being a singleton).
422         As the object allocation sinking phase assumes object allocation is
423         free of side-effects, sinking these allocations is not correct.
424
425         This also means that when materializing a function allocation on OSR
426         exit, that function's executable will never be a singleton, and we don't have
427         to worry about its watchpoint, allowing us to use
428         JSFunction::createWithInvalidatedRellocationWatchpoint instead of
429         JSFunction::create.
430
431         * dfg/DFGObjectAllocationSinkingPhase.cpp:
432         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
433         * ftl/FTLOperations.cpp:
434         (JSC::FTL::operationMaterializeObjectInOSR):
435
436 2015-04-30  Jon Davis  <jond@apple.com>
437
438         Web Inspector: console should show an icon for console.info() messages
439         https://bugs.webkit.org/show_bug.cgi?id=18530
440
441         Reviewed by Timothy Hatcher.
442
443         * inspector/ConsoleMessage.cpp:
444         (Inspector::messageLevelValue):
445         * inspector/protocol/Console.json:
446         * runtime/ConsoleClient.cpp:
447         (JSC::appendMessagePrefix):
448         * runtime/ConsolePrototype.cpp:
449         (JSC::ConsolePrototype::finishCreation):
450         (JSC::consoleProtoFuncInfo):
451         * runtime/ConsoleTypes.h:
452
453 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
454
455         Move all of the branchIs<type> helpers from SpeculativeJIT into AssemblyHelpers
456         https://bugs.webkit.org/show_bug.cgi?id=144462
457
458         Reviewed by Geoffrey Garen and Mark Lam.
459         
460         At some point we started adding representation-agnostic helpers for doing common type tests.
461         We added some in SpeculativeJIT, and then some in AssemblyHelpers. Prior to this change,
462         they had overlapping powers, though SpeculativeJIT was a bit better.
463         
464         This removes SpeculativeJIT's helpers and strengthens AssemblyHelpers' helpers. This is
465         better because now all of these helpers can be used in all of the assembly-based JITs, not
466         just the DFG. It also settles on what I find to be a slightly better naming convention.
467         For example where we previously would have said branchIsString, now we say
468         branchIfString. Similarly, branchNotString becomes branchIfNotString.
469
470         * dfg/DFGSpeculativeJIT.cpp:
471         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
472         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
473         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
474         (JSC::DFG::SpeculativeJIT::compileInstanceOf):
475         (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
476         (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
477         (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
478         (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
479         (JSC::DFG::SpeculativeJIT::speculateObject):
480         (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
481         (JSC::DFG::SpeculativeJIT::speculateString):
482         (JSC::DFG::SpeculativeJIT::speculateNotStringVar):
483         (JSC::DFG::SpeculativeJIT::speculateNotCell):
484         (JSC::DFG::SpeculativeJIT::speculateOther):
485         (JSC::DFG::SpeculativeJIT::emitSwitchChar):
486         (JSC::DFG::SpeculativeJIT::emitSwitchString):
487         (JSC::DFG::SpeculativeJIT::branchIsObject): Deleted.
488         (JSC::DFG::SpeculativeJIT::branchNotObject): Deleted.
489         (JSC::DFG::SpeculativeJIT::branchIsString): Deleted.
490         (JSC::DFG::SpeculativeJIT::branchNotString): Deleted.
491         * dfg/DFGSpeculativeJIT.h:
492         * dfg/DFGSpeculativeJIT32_64.cpp:
493         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
494         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
495         (JSC::DFG::SpeculativeJIT::emitCall):
496         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
497         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
498         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
499         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
500         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
501         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
502         (JSC::DFG::SpeculativeJIT::compile):
503         (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
504         (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
505         (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
506         (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
507         * dfg/DFGSpeculativeJIT64.cpp:
508         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
509         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
510         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
511         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
512         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
513         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
514         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
515         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
516         (JSC::DFG::SpeculativeJIT::compile):
517         (JSC::DFG::SpeculativeJIT::writeBarrier):
518         (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
519         (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
520         (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
521         (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
522         * jit/AssemblyHelpers.h:
523         (JSC::AssemblyHelpers::branchIfCell):
524         (JSC::AssemblyHelpers::branchIfOther):
525         (JSC::AssemblyHelpers::branchIfNotOther):
526         (JSC::AssemblyHelpers::branchIfObject):
527         (JSC::AssemblyHelpers::branchIfNotObject):
528         (JSC::AssemblyHelpers::branchIfType):
529         (JSC::AssemblyHelpers::branchIfNotType):
530         (JSC::AssemblyHelpers::branchIfString):
531         (JSC::AssemblyHelpers::branchIfNotString):
532         (JSC::AssemblyHelpers::branchIfSymbol):
533         (JSC::AssemblyHelpers::branchIfNotSymbol):
534         (JSC::AssemblyHelpers::branchIfFunction):
535         (JSC::AssemblyHelpers::branchIfNotFunction):
536         (JSC::AssemblyHelpers::branchIfEmpty):
537         (JSC::AssemblyHelpers::branchIsEmpty): Deleted.
538         (JSC::AssemblyHelpers::branchIfCellNotObject): Deleted.
539         * jit/JITPropertyAccess.cpp:
540         (JSC::JIT::emitScopedArgumentsGetByVal):
541
542 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
543
544         js/regress/is-string-fold-tricky.html and js/regress/is-string-fold.html are crashing
545         https://bugs.webkit.org/show_bug.cgi?id=144463
546
547         Reviewed by Benjamin Poulain.
548         
549         Fixup phase was super cleverly folding an IsString(@x) when @x is predicted SpecString
550         into a Check(String:@x) followed by JSConstant(true). Then in these tests the
551         ValueAdd(IsString(@x), @stuff) would try to turn this into an integer add by cleverly
552         converting the boolean into an integer. But as part of doing that, it would try to
553         short-circuit any profiling by leveraging the fact that the IsString is now a constant,
554         and it would try to figure out if the addition might overflow. Part of that logic
555         involved checking if the immediate is either a boolean or a sufficiently small integer.
556         But: it would check if it's a sufficiently small integer before checking if it was a
557         boolean, so it would try to call asNumber() on the boolean.
558         
559         All of this cleverness was very deliberate, but apparently the @stuff + booleanConstant
560         case was previously never hit until I wrote these tests, and so we never knew that
561         calling asNumber() on a boolean was wrong.
562         
563         The fix is super simple: the expression should just check for boolean first.
564         
565         This bug was benign in release builds. JSValue::asNumber() on a boolean would return
566         garbage, and that's OK, since we'd take the boolean case anyway.
567
568         * dfg/DFGGraph.h:
569         (JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
570
571 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
572
573         Unreviewed, add a FIXME comment referencing https://bugs.webkit.org/show_bug.cgi?id=144458.
574
575         * jit/JITOperations.cpp:
576
577 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
578
579         Add a comment clarifying the behavior and semantics of getCallData/getConstructData, in
580         particular that they cannot change their minds and may be called from compiler threads.
581
582         Rubber stamped by Geoffrey Garen.
583
584         * runtime/JSCell.h:
585
586 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
587
588         DFG Is<Blah> versions of TypeOf should fold based on proven input type
589         https://bugs.webkit.org/show_bug.cgi?id=144409
590
591         Reviewed by Geoffrey Garen.
592         
593         We were missing some obvious folding opportunities here. I don't know how this affects real
594         code, but in general, we like to ensure that our constant folding is comprehensive. So this
595         is more about placating my static analysis OCD than anything else.
596         
597         I added a bunch of speed/correctness tests for this in LayoutTests/js/regress.
598
599         * dfg/DFGAbstractInterpreterInlines.h:
600         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
601
602 2015-04-30  Yusuke Suzuki  <utatane.tea@gmail.com>
603
604         Use the default hash value for Symbolized StringImpl
605         https://bugs.webkit.org/show_bug.cgi?id=144347
606
607         Reviewed by Darin Adler.
608
609         Before this patch, symbolized StringImpl* has a special hash value
610         to avoid the hash collision with the other normal StringImpl*.
611         I guess that it is introduced when private symbols are introduced.
612         However, it prevents using symbolized StringImpl* in the other place
613         For example, using it as WTFString cause a problem because of its special hash value.
614
615         When only using private symbols, they are not exposed to the outside of JSC,
616         so we can handle it carefully. But now, it's extended to symbols.
617         So I think storing a special hash value in StringImpl* causes an error.
618
619         To avoid this, I propose using the usual hash value in symbolized StringImpl*.
620         And to provide significantly different hash value when using it as symbol,
621         store the additional hash value in symbolized StringImpl*. It is used when
622         the hash value is required by IdentifierRepHash.
623
624         * runtime/Identifier.h:
625         (JSC::IdentifierRepHash::hash):
626         * runtime/Lookup.h:
627         (JSC::HashTable::entry):
628         * runtime/PropertyMapHashTable.h:
629         (JSC::PropertyTable::find):
630         (JSC::PropertyTable::get):
631         * runtime/Structure.cpp:
632         (JSC::PropertyTable::checkConsistency):
633
634 2015-04-29  Benjamin Poulain  <bpoulain@apple.com>
635
636         [JSC] Remove RageConvert array conversion
637         https://bugs.webkit.org/show_bug.cgi?id=144433
638
639         Reviewed by Filip Pizlo.
640
641         RageConvert was causing a subtle bug that was hitting the Kraken crypto tests
642         pretty hard:
643         -The indexing types shows that the array access varies between Int32 and DoubleArray.
644         -ArrayMode::fromObserved() decided to use the most generic type: DoubleArray.
645          An Arrayify node would convert the Int32 to that type.
646         -Somewhere, a GetByVal or PutByVal would have the flag NodeBytecodeUsesAsInt. That
647          node would use RageConvert instead of Convert.
648         -The Arrayify for that GetByVal with RageConvert would not convert the array to
649          Contiguous.
650         -All the following array access that do not have the flag NodeBytecodeUsesAsInt would
651          now expect a DoubleArray and always get a Contiguous Array. The CheckStructure
652          fail systematically and we never get to run the later code.
653
654         Getting rid of RageConvert fixes the problem and does not seems to have any
655         negative side effect on other benchmarks.
656
657         The improvments on Kraken are:
658             -stanford-crypto-aes: definitely 1.0915x faster.
659             -stanford-crypto-pbkdf2: definitely 1.2446x faster.
660             -stanford-crypto-sha256-iterative: definitely 1.0544x faster.
661
662         * dfg/DFGAbstractInterpreterInlines.h:
663         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
664         * dfg/DFGArrayMode.cpp:
665         (JSC::DFG::ArrayMode::refine):
666         (JSC::DFG::arrayConversionToString):
667         * dfg/DFGArrayMode.h:
668         * dfg/DFGArrayifySlowPathGenerator.h:
669         * dfg/DFGFixupPhase.cpp:
670         (JSC::DFG::FixupPhase::fixupNode):
671         * dfg/DFGOperations.cpp:
672         * dfg/DFGOperations.h:
673         * dfg/DFGPredictionPropagationPhase.cpp:
674         (JSC::DFG::PredictionPropagationPhase::propagate):
675         * dfg/DFGTypeCheckHoistingPhase.cpp:
676         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
677         * ftl/FTLLowerDFGToLLVM.cpp:
678         (JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
679         * runtime/JSObject.cpp:
680         (JSC::JSObject::convertDoubleToContiguous):
681         (JSC::JSObject::ensureContiguousSlow):
682         (JSC::JSObject::genericConvertDoubleToContiguous): Deleted.
683         (JSC::JSObject::rageConvertDoubleToContiguous): Deleted.
684         (JSC::JSObject::rageEnsureContiguousSlow): Deleted.
685         * runtime/JSObject.h:
686         (JSC::JSObject::rageEnsureContiguous): Deleted.
687
688 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
689
690         Gracefully handle missing auto pause key on remote inspector setup
691         https://bugs.webkit.org/show_bug.cgi?id=144411
692
693         Reviewed by Timothy Hatcher.
694
695         * inspector/remote/RemoteInspector.mm:
696         (Inspector::RemoteInspector::receivedSetupMessage):
697
698 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
699
700         NodeList has issues with Symbol and empty string
701         https://bugs.webkit.org/show_bug.cgi?id=144310
702
703         Reviewed by Darin Adler.
704
705         * runtime/PropertyName.h:
706         (JSC::PropertyName::isSymbol):
707         Helper to check if the PropertyName is a string or symbol property.
708
709 2015-04-29  Alex Christensen  <achristensen@webkit.org>
710
711         Fix non-cygwin incremental builds on Windows.
712         https://bugs.webkit.org/show_bug.cgi?id=143264
713
714         Reviewed by Brent Fulgham.
715
716         * generate-js-builtins:
717         Remove stale headers before calling os.rename to replace them.
718
719 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
720
721         JSTypeInfo should have an inline type flag to indicate of getCallData() has been overridden
722         https://bugs.webkit.org/show_bug.cgi?id=144397
723
724         Reviewed by Andreas Kling.
725         
726         Add the flag to JSTypeInfo. It's an inline flag so that it's fast to query. Slap the flag on
727         callback objects and internal functions. Modify the TypeOf operation to use this flag to avoid
728         making a getCallData() call if it isn't necessary.
729
730         * API/JSCallbackObject.h:
731         * runtime/InternalFunction.h:
732         * runtime/JSTypeInfo.h:
733         (JSC::TypeInfo::typeOfShouldCallGetCallData):
734         * runtime/Operations.cpp:
735         (JSC::jsTypeStringForValue):
736         * tests/stress/type-of-functions-and-objects.js: Added.
737         (foo):
738         (bar):
739         (baz):
740         (fuzz):
741         (expect):
742         (test):
743
744 2015-04-28  Geoffrey Garen  <ggaren@apple.com>
745
746         It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
747         https://bugs.webkit.org/show_bug.cgi?id=144013
748
749         Reviewed by Mark Lam.
750
751         This patch implements Array.prototype.sort in JavaScript, removing the
752         C++ implementations. It is simpler and less error-prone to express our
753         operations in JavaScript, which provides memory safety, exception safety,
754         and recursion safety.
755
756         The performance result is mixed, but net positive in my opinion. It's
757         difficult to enumerate all the results, since we used to have so many
758         different sorting modes, and there are lots of different data patterns
759         across which you might want to measure sorting. Suffice it to say:
760
761             (*) The benchmarks we track are faster or unchanged.
762
763             (*) Sorting random input using a comparator -- which we think is
764             common -- is 3X faster.
765
766             (*) Sorting random input in a non-array object -- which jQuery does
767             -- is 4X faster.
768
769             (*) Sorting random input in a compact array of integers using a
770             trivial pattern-matchable comparator is 2X *slower*.
771
772         * builtins/Array.prototype.js:
773         (sort.min):
774         (sort.stringComparator):
775         (sort.compactSparse): Special case compaction for sparse arrays because
776         we don't want to hang when sorting new Array(BIG).
777
778         (sort.compact):
779         (sort.merge):
780         (sort.mergeSort): Use merge sort because it's a reasonably efficient
781         stable sort. We have evidence that some sites depend on stable sort,
782         even though the ES6 spec does not mandate it. (See
783         <http://trac.webkit.org/changeset/33967>.)
784
785         This is a textbook implementation of merge sort with three optimizations:
786
787             (1) Use iteration instead of recursion;
788
789             (2) Use array subscripting instead of array copying in order to
790             create logical sub-lists without creating physical sub-lists;
791
792             (3) Swap src and dst at each iteration instead of copying src into
793             dst, and only copy src into the subject array at the end if src is
794             not the subject array.
795
796         (sort.inflate):
797         (sort.comparatorSort):
798         (sort): Sort in JavaScript for the win.
799
800         * builtins/BuiltinExecutables.cpp:
801         (JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
802         names so we can use helper functions.
803
804         * bytecode/CodeBlock.h:
805         (JSC::CodeBlock::isNumericCompareFunction): Deleted.
806         * bytecode/UnlinkedCodeBlock.cpp:
807         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
808         * bytecode/UnlinkedCodeBlock.h:
809         (JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
810         (JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
811         * bytecompiler/BytecodeGenerator.cpp:
812         (JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
813         * bytecompiler/BytecodeGenerator.h:
814         * bytecompiler/NodesCodegen.cpp:
815         (JSC::FunctionNode::emitBytecode): We don't do this special casing based
816         on pattern matching anymore. This was mainly an optimization to avoid 
817         the overhead of calling from C++ to JS, which we now avoid by
818         sorting in JS.
819
820         * heap/Heap.cpp:
821         (JSC::Heap::markRoots):
822         (JSC::Heap::pushTempSortVector): Deleted.
823         (JSC::Heap::popTempSortVector): Deleted.
824         (JSC::Heap::visitTempSortVectors): Deleted.
825         * heap/Heap.h: We don't have temp sort vectors anymore because we sort
826         in JavaScript using a normal JavaScript array for our temporary storage.
827
828         * parser/Parser.cpp:
829         (JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
830         helper functions.
831
832         * runtime/ArrayPrototype.cpp:
833         (JSC::isNumericCompareFunction): Deleted.
834         (JSC::attemptFastSort): Deleted.
835         (JSC::performSlowSort): Deleted.
836         (JSC::arrayProtoFuncSort): Deleted.
837
838         * runtime/CommonIdentifiers.h: New strings used by sort.
839
840         * runtime/JSArray.cpp:
841         (JSC::compareNumbersForQSortWithInt32): Deleted.
842         (JSC::compareNumbersForQSortWithDouble): Deleted.
843         (JSC::compareNumbersForQSort): Deleted.
844         (JSC::compareByStringPairForQSort): Deleted.
845         (JSC::JSArray::sortNumericVector): Deleted.
846         (JSC::JSArray::sortNumeric): Deleted.
847         (JSC::ContiguousTypeAccessor::getAsValue): Deleted.
848         (JSC::ContiguousTypeAccessor::setWithValue): Deleted.
849         (JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
850         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
851         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
852         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
853         (JSC::JSArray::sortCompactedVector): Deleted.
854         (JSC::JSArray::sort): Deleted.
855         (JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
856         (JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
857         (JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
858         (JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
859         (JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
860         (JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
861         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
862         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
863         (JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
864         (JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
865         (JSC::JSArray::sortVector): Deleted.
866         (JSC::JSArray::compactForSorting): Deleted.
867         * runtime/JSArray.h:
868
869         * runtime/JSGlobalObject.cpp:
870         (JSC::JSGlobalObject::init):
871         * runtime/ObjectConstructor.cpp:
872         (JSC::ObjectConstructor::finishCreation): Provide some builtins used
873         by sort.
874
875 2015-04-29  Mark Lam  <mark.lam@apple.com>
876
877         Safari WebKit crash when loading Google Spreadsheet.
878         https://bugs.webkit.org/show_bug.cgi?id=144020
879
880         Reviewed by Filip Pizlo.
881
882         The bug is that the object allocation sinking phase did not account for a case
883         where a property of a sunken object is only initialized on one path and not
884         another.  As a result, on the path where the property is not initialized, we'll
885         encounter an Upsilon with a BottomValue (which is not allowed by definition).
886
887         The fix is to use a JSConstant(undefined) as the bottom value instead (of
888         BottomValue).  If the property is uninitialized, it should still be accessible
889         and have the value undefined.
890
891         * dfg/DFGObjectAllocationSinkingPhase.cpp:
892         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
893         * tests/stress/object-allocation-sinking-with-uninitialized-property-on-one-path.js: Added.
894         (foo):
895         (foo2):
896
897 2015-04-29  Yusuke Suzuki  <utatane.tea@gmail.com>
898
899         REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
900         https://bugs.webkit.org/show_bug.cgi?id=144257
901
902         Reviewed by Darin Adler.
903
904         SHA1 is used to calculate CodeBlockHash.
905         To calculate hash value, we pass the source code UTF-8 CString to SHA1::addBytes.
906         However, the source code can contain null character.
907         So when performing `strlen` on the source code's CString, it returns the incorrect length.
908         In SHA1::addBytes, there's assertion `input.length() == strlen(string)` and it fails.
909
910         In the template-literal-syntax.js, we perform `eval` with the script contains "\0".
911         As the result, `strlen(string)` accidentally shortened by the contained "\0", and assertion fails.
912
913         CString will be changed not to contain a null-character[1]. However, inserting the assertion here
914         is not correct. Because
915
916         1. If CString should not contain a null character, this should be asserted in CString side instead of SHA1::addBytes.
917         2. If CString can contain a null character, this assertion becomes incorrect.
918
919         So this patch just drops the assertion.
920
921         In the current implementation, we once convert the entire source code to the newly allocated
922         UTF-8 string and pass it to the SHA1 processing. However, this is memory consuming.
923         Ideally, we should stream the decoded bytes into the SHA1 processing iteratively.
924         We'll implement it in the separate patch[2].
925
926         [1]: https://bugs.webkit.org/show_bug.cgi?id=144339
927         [2]: https://bugs.webkit.org/show_bug.cgi?id=144263
928
929         * tests/stress/eval-script-contains-null-character.js: Added.
930         (shouldBe):
931         (test):
932         * tests/stress/template-literal-line-terminators.js:
933         * tests/stress/template-literal-syntax.js:
934         * tests/stress/template-literal.js:
935
936 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
937
938         Evict IsEnvironmentRecord from inline type flags
939         https://bugs.webkit.org/show_bug.cgi?id=144398
940
941         Reviewed by Mark Lam and Michael Saboff.
942         
943         In https://bugs.webkit.org/show_bug.cgi?id=144397, we'll need an extra bit in the inline
944         type flags. This change picks the least important inline type flag - IsEnvironmentRecord -
945         and evicts it into the out-of-line type flags. This change has no performance implications
946         because we never even accessed IsEnvironmentRecord via the StructureIDBlob. The only place
947         where we access it at all is in String.prototype.repeat, and there we already load the
948         structure anyway.
949
950         * runtime/JSTypeInfo.h:
951         (JSC::TypeInfo::implementsHasInstance):
952         (JSC::TypeInfo::structureIsImmortal):
953         (JSC::TypeInfo::isEnvironmentRecord):
954
955 2015-04-29  Darin Adler  <darin@apple.com>
956
957         [ES6] Implement Unicode code point escapes
958         https://bugs.webkit.org/show_bug.cgi?id=144377
959
960         Reviewed by Antti Koivisto.
961
962         * parser/Lexer.cpp: Moved the UnicodeHexValue class in here from
963         the header. Made it a non-member class so it doesn't need to be part
964         of a template. Made it use UChar32 instead of int for the value to
965         make it clearer what goes into this class.
966         (JSC::ParsedUnicodeEscapeValue::isIncomplete): Added. Replaces the
967         old type() function.
968         (JSC::Lexer<CharacterType>::parseUnicodeEscape): Renamed from
969         parseFourDigitUnicodeHex and added support for code point escapes.
970         (JSC::isLatin1): Added an overload for UChar32.
971         (JSC::isIdentStart): Changed this to take UChar32; no caller tries
972         to call it with a UChar, so no need to overload for that type for now.
973         (JSC::isNonLatin1IdentPart): Changed argument type to UChar32 for clarity.
974         Also added FIXME about a subtle ES6 change that we might want to make later.
975         (JSC::isIdentPart): Changed this to take UChar32; no caller tries
976         to call it with a UChar, so no need to overload for that type for now.
977         (JSC::isIdentPartIncludingEscapeTemplate): Made this a template so that we
978         don't need to repeat the code twice. Added code to handle code point escapes.
979         (JSC::isIdentPartIncludingEscape): Call the template instead of having the
980         code in line.
981         (JSC::Lexer<CharacterType>::recordUnicodeCodePoint): Added.
982         (JSC::Lexer<CharacterType>::parseIdentifierSlowCase): Made small tweaks and
983         updated to call parseUnicodeEscape instead of parseFourDigitUnicodeHex.
984         (JSC::Lexer<CharacterType>::parseComplexEscape): Call parseUnicodeEscape
985         instead of parseFourDigitUnicodeHex. Move the code to handle "\u" before
986         the code that handles the escapes, since the code point escape code now
987         consumes characters while parsing rather than peeking ahead. Test case
988         covers this: Symptom would be that "\u{" would evaluate to "u" instead of
989         giving a syntax error.
990
991         * parser/Lexer.h: Updated for above changes.
992
993         * runtime/StringConstructor.cpp:
994         (JSC::stringFromCodePoint): Use ICU's UCHAR_MAX_VALUE instead of writing
995         out 0x10FFFF; clearer this way.
996
997 2015-04-29  Martin Robinson  <mrobinson@igalia.com>
998
999         [CMake] [GTK] Organize and clean up unused CMake variables
1000         https://bugs.webkit.org/show_bug.cgi?id=144364
1001
1002         Reviewed by Gyuyoung Kim.
1003
1004         * PlatformGTK.cmake: Add variables specific to this project.
1005
1006 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
1007
1008         TypeOf should return SpecStringIdent and the DFG should know this
1009         https://bugs.webkit.org/show_bug.cgi?id=144376
1010
1011         Reviewed by Andreas Kling.
1012         
1013         Make TypeOf return atomic strings. That's a simple change in SmallStrings.
1014         
1015         Make the DFG know this and use it for optimization. This makes Switch(TypeOf) a bit less
1016         bad.
1017
1018         * dfg/DFGAbstractInterpreterInlines.h:
1019         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1020         * dfg/DFGAbstractValue.cpp:
1021         (JSC::DFG::AbstractValue::setType):
1022         * dfg/DFGAbstractValue.h:
1023         (JSC::DFG::AbstractValue::setType):
1024         * dfg/DFGInPlaceAbstractState.cpp:
1025         (JSC::DFG::InPlaceAbstractState::initialize):
1026         * dfg/DFGPredictionPropagationPhase.cpp:
1027         (JSC::DFG::PredictionPropagationPhase::propagate):
1028         * runtime/SmallStrings.cpp:
1029         (JSC::SmallStrings::initialize):
1030         * tests/stress/switch-typeof-indirect.js: Added.
1031         (bar):
1032         (foo):
1033         (test):
1034         * tests/stress/switch-typeof-slightly-indirect.js: Added.
1035         (foo):
1036         (test):
1037         * tests/stress/switch-typeof.js: Added.
1038         (foo):
1039         (test):
1040
1041 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
1042
1043         REGRESSION(181868): Windows Live SkyDrive cannot open an excel file
1044         https://bugs.webkit.org/show_bug.cgi?id=144373
1045
1046         Reviewed by Darin Adler.
1047
1048         Revert r181868 as it caused a failure on live.com. We can try
1049         re-enabling this exception after we make idl attributes configurable,
1050         which may have prevented this particular failure.
1051
1052         * runtime/ObjectPrototype.cpp:
1053         (JSC::objectProtoFuncDefineGetter):
1054         (JSC::objectProtoFuncDefineSetter):
1055
1056 2015-04-28  Joseph Pecoraro  <pecoraro@apple.com>
1057
1058         Deadlock on applications using JSContext on non-main thread
1059         https://bugs.webkit.org/show_bug.cgi?id=144370
1060
1061         Reviewed by Timothy Hatcher.
1062
1063         * inspector/remote/RemoteInspector.mm:
1064         (Inspector::RemoteInspector::singleton):
1065         Prevent a possible deadlock by assuming we can synchronously
1066         run something on the main queue at this time.
1067
1068 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
1069
1070         FTL should fully support Switch (it currently lacks the SwitchString variant)
1071         https://bugs.webkit.org/show_bug.cgi?id=144348
1072
1073         Reviewed by Benjamin Poulain.
1074         
1075         This adds SwitchString support to the FTL. This is already tested by switch microbenchmarks
1076         in LayoutTests/js/regress.
1077
1078         * dfg/DFGCommon.cpp:
1079         (JSC::DFG::stringLessThan):
1080         * dfg/DFGCommon.h:
1081         * dfg/DFGOperations.cpp:
1082         * dfg/DFGOperations.h:
1083         * dfg/DFGSpeculativeJIT.cpp:
1084         (JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<): Deleted.
1085         * dfg/DFGSpeculativeJIT.h:
1086         (JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<):
1087         * ftl/FTLCapabilities.cpp:
1088         (JSC::FTL::canCompile):
1089         * ftl/FTLIntrinsicRepository.h:
1090         * ftl/FTLLowerDFGToLLVM.cpp:
1091         (JSC::FTL::LowerDFGToLLVM::compileSwitch):
1092         (JSC::FTL::LowerDFGToLLVM::switchString):
1093         (JSC::FTL::LowerDFGToLLVM::StringSwitchCase::StringSwitchCase):
1094         (JSC::FTL::LowerDFGToLLVM::StringSwitchCase::operator<):
1095         (JSC::FTL::LowerDFGToLLVM::CharacterCase::CharacterCase):
1096         (JSC::FTL::LowerDFGToLLVM::CharacterCase::operator<):
1097         (JSC::FTL::LowerDFGToLLVM::switchStringRecurse):
1098         (JSC::FTL::LowerDFGToLLVM::switchStringSlow):
1099         (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
1100         * ftl/FTLOutput.cpp:
1101         (JSC::FTL::Output::check):
1102         * ftl/FTLOutput.h:
1103         * ftl/FTLWeight.h:
1104         (JSC::FTL::Weight::inverse):
1105         * jit/JITOperations.h:
1106
1107 2015-04-28  Michael Catanzaro  <mcatanzaro@igalia.com>
1108
1109         Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT
1110         https://bugs.webkit.org/show_bug.cgi?id=144304
1111
1112         Reviewed by Geoffrey Garen.
1113
1114         * Configurations/FeatureDefines.xcconfig: Define ENABLE_JIT, enabled by default, instead of
1115         ENABLE_LLINT_C_LOOP, disabled by default.
1116         * llint/LLIntSlowPaths.cpp:
1117         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Check ENABLE_JIT instead of ENABLE_LLINT_C_LOOP.
1118
1119 2015-04-28  Commit Queue  <commit-queue@webkit.org>
1120
1121         Unreviewed, rolling out r183514.
1122         https://bugs.webkit.org/show_bug.cgi?id=144359
1123
1124         It broke cloop test bots (Requested by mcatanzaro on #webkit).
1125
1126         Reverted changeset:
1127
1128         "Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT"
1129         https://bugs.webkit.org/show_bug.cgi?id=144304
1130         http://trac.webkit.org/changeset/183514
1131
1132 2015-04-28  Michael Catanzaro  <mcatanzaro@igalia.com>
1133
1134         Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT
1135         https://bugs.webkit.org/show_bug.cgi?id=144304
1136
1137         Reviewed by Geoffrey Garen.
1138
1139         * Configurations/FeatureDefines.xcconfig: Define ENABLE_JIT, enabled by default, instead of
1140         ENABLE_LLINT_C_LOOP, disabled by default.
1141         * llint/LLIntSlowPaths.cpp:
1142         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Check ENABLE_JIT instead of ENABLE_LLINT_C_LOOP.
1143
1144 2015-04-28  Joseph Pecoraro  <pecoraro@apple.com>
1145
1146         Fix common typo "targetting" => "targeting"
1147         https://bugs.webkit.org/show_bug.cgi?id=144349
1148
1149         Reviewed by Daniel Bates.
1150
1151         * bytecode/ExecutionCounter.h:
1152
1153 2015-04-28  Yusuke Suzuki  <utatane.tea@gmail.com>
1154
1155         Update the features.json for WeakSet, WeakMap, Template literals, Tagged templates
1156         https://bugs.webkit.org/show_bug.cgi?id=144328
1157
1158         Reviewed by Andreas Kling.
1159
1160         Update the status of ES6 features.
1161
1162         * features.json:
1163
1164 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
1165
1166         DFG should not use or preserve Phantoms during transformations
1167         https://bugs.webkit.org/show_bug.cgi?id=143736
1168
1169         Reviewed by Geoffrey Garen.
1170         
1171         Since http://trac.webkit.org/changeset/183207 and http://trac.webkit.org/changeset/183406, it is
1172         no longer necessary to preserve Phantoms during transformations. They are still useful just
1173         before FixupPhase to support backwards propagation analyses. They are still inserted late in the
1174         game in the DFG backend. But transformations don't need to worry about them. Inside a basic
1175         block, we can be sure that so long as the IR pinpoints the place where the value becomes
1176         available in a bytecode register (using MovHint) and so long as there is a SetLocal anytime some
1177         other block would need the value (either for OSR or for DFG execution), then we don't need any
1178         liveness markers.
1179         
1180         So, this removes any places where we inserted Phantoms just for liveness during transformation
1181         and it replaces convertToPhantom() with remove(), which just converts the node to a Check. A
1182         Check node only keeps its children so long as those children have checks.
1183         
1184         The fact that we no longer convertToPhantom() means that we have to be more careful when
1185         constant-folding GetLocal. Previously we would convertToPhantom() and use the fact that
1186         Phantom(Phi) was a valid construct. It's not valid anymore. So, when constant folding encounters
1187         a GetLocal it needs to insert a PhantomLocal directly. This allows us to simplify
1188         Graph::convertToConstant() a bit. Luckily, none of the other users of this method would see
1189         GetLocals.
1190         
1191         The only Phantom-like cruft left over after this patch is:
1192         
1193         - Phantoms before FixupPhase. I kind of like these. It means that before FixupPhase, we can do
1194           backwards analyses and rely on the fact that the users of a node in DFG IR are a superset of
1195           the users of the original local's live range in bytecode. This is essential for supporting our
1196           BackwardsPropagationPhase, which is an important optimization for things like asm.js.
1197         
1198         - PhantomLocals and GetLocals being NodeMustGenerate. See discussion in
1199           https://bugs.webkit.org/show_bug.cgi?id=144086. It appears that this is not as evil as the
1200           alternatives. The best long-term plan is to simply ditch the ThreadedCPS IR entirely and have
1201           the DFG use SSA. For now, so long as any new DFG optimizations we add are block-local and
1202           treat GetLocal/SetLocal conservatively, this should all be sound.
1203         
1204         This change should be perf-neutral although it does reduce the total work that the compiler
1205         does.
1206
1207         * CMakeLists.txt:
1208         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1209         * JavaScriptCore.xcodeproj/project.pbxproj:
1210         * dfg/DFGAdjacencyList.h:
1211         (JSC::DFG::AdjacencyList::justChecks):
1212         * dfg/DFGArgumentsEliminationPhase.cpp:
1213         * dfg/DFGBasicBlock.cpp:
1214         (JSC::DFG::BasicBlock::replaceTerminal):
1215         * dfg/DFGBasicBlock.h:
1216         (JSC::DFG::BasicBlock::findTerminal):
1217         * dfg/DFGCFGSimplificationPhase.cpp:
1218         (JSC::DFG::CFGSimplificationPhase::keepOperandAlive):
1219         (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
1220         * dfg/DFGCPSRethreadingPhase.cpp:
1221         (JSC::DFG::CPSRethreadingPhase::CPSRethreadingPhase):
1222         (JSC::DFG::CPSRethreadingPhase::clearVariables):
1223         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
1224         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
1225         * dfg/DFGCSEPhase.cpp:
1226         * dfg/DFGCleanUpPhase.cpp: Copied from Source/JavaScriptCore/dfg/DFGPhantomRemovalPhase.cpp.
1227         (JSC::DFG::CleanUpPhase::CleanUpPhase):
1228         (JSC::DFG::CleanUpPhase::run):
1229         (JSC::DFG::performCleanUp):
1230         (JSC::DFG::PhantomRemovalPhase::PhantomRemovalPhase): Deleted.
1231         (JSC::DFG::PhantomRemovalPhase::run): Deleted.
1232         (JSC::DFG::performPhantomRemoval): Deleted.
1233         * dfg/DFGCleanUpPhase.h: Copied from Source/JavaScriptCore/dfg/DFGPhantomRemovalPhase.h.
1234         * dfg/DFGConstantFoldingPhase.cpp:
1235         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1236         (JSC::DFG::ConstantFoldingPhase::addBaseCheck):
1237         (JSC::DFG::ConstantFoldingPhase::fixUpsilons):
1238         * dfg/DFGDCEPhase.cpp:
1239         (JSC::DFG::DCEPhase::run):
1240         (JSC::DFG::DCEPhase::fixupBlock):
1241         (JSC::DFG::DCEPhase::cleanVariables):
1242         * dfg/DFGFixupPhase.cpp:
1243         (JSC::DFG::FixupPhase::fixupBlock):
1244         (JSC::DFG::FixupPhase::fixupNode):
1245         (JSC::DFG::FixupPhase::convertStringAddUse):
1246         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
1247         (JSC::DFG::FixupPhase::checkArray):
1248         (JSC::DFG::FixupPhase::fixIntConvertingEdge):
1249         (JSC::DFG::FixupPhase::fixIntOrBooleanEdge):
1250         (JSC::DFG::FixupPhase::fixDoubleOrBooleanEdge):
1251         (JSC::DFG::FixupPhase::injectTypeConversionsInBlock):
1252         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
1253         (JSC::DFG::FixupPhase::injectTypeConversionsForEdge):
1254         (JSC::DFG::FixupPhase::addRequiredPhantom): Deleted.
1255         (JSC::DFG::FixupPhase::addPhantomsIfNecessary): Deleted.
1256         * dfg/DFGGraph.cpp:
1257         (JSC::DFG::Graph::convertToConstant):
1258         (JSC::DFG::Graph::mergeRelevantToOSR): Deleted.
1259         * dfg/DFGGraph.h:
1260         * dfg/DFGInsertionSet.h:
1261         (JSC::DFG::InsertionSet::insertCheck):
1262         * dfg/DFGIntegerCheckCombiningPhase.cpp:
1263         (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
1264         * dfg/DFGLICMPhase.cpp:
1265         (JSC::DFG::LICMPhase::attemptHoist):
1266         * dfg/DFGNode.cpp:
1267         (JSC::DFG::Node::remove):
1268         * dfg/DFGNode.h:
1269         (JSC::DFG::Node::replaceWith):
1270         (JSC::DFG::Node::convertToPhantom): Deleted.
1271         (JSC::DFG::Node::convertToCheck): Deleted.
1272         (JSC::DFG::Node::willHaveCodeGenOrOSR): Deleted.
1273         * dfg/DFGNodeFlags.h:
1274         * dfg/DFGNodeType.h:
1275         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1276         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
1277         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1278         * dfg/DFGPhantomCanonicalizationPhase.cpp: Removed.
1279         * dfg/DFGPhantomCanonicalizationPhase.h: Removed.
1280         * dfg/DFGPhantomRemovalPhase.cpp: Removed.
1281         * dfg/DFGPhantomRemovalPhase.h: Removed.
1282         * dfg/DFGPlan.cpp:
1283         (JSC::DFG::Plan::compileInThreadImpl):
1284         * dfg/DFGPutStackSinkingPhase.cpp:
1285         * dfg/DFGResurrectionForValidationPhase.cpp: Removed.
1286         * dfg/DFGResurrectionForValidationPhase.h: Removed.
1287         * dfg/DFGSSAConversionPhase.cpp:
1288         (JSC::DFG::SSAConversionPhase::run):
1289         * dfg/DFGSpeculativeJIT64.cpp:
1290         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
1291         * dfg/DFGStoreBarrierElisionPhase.cpp:
1292         (JSC::DFG::StoreBarrierElisionPhase::elideBarrier):
1293         * dfg/DFGStrengthReductionPhase.cpp:
1294         (JSC::DFG::StrengthReductionPhase::handleNode):
1295         (JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild):
1296         * dfg/DFGValidate.cpp:
1297         (JSC::DFG::Validate::validate):
1298         (JSC::DFG::Validate::validateCPS):
1299         (JSC::DFG::Validate::validateSSA):
1300         * dfg/DFGVarargsForwardingPhase.cpp:
1301         * ftl/FTLLink.cpp:
1302         (JSC::FTL::link):
1303         * ftl/FTLLowerDFGToLLVM.cpp:
1304         (JSC::FTL::LowerDFGToLLVM::compileNode):
1305         (JSC::FTL::LowerDFGToLLVM::compileNoOp):
1306         (JSC::FTL::LowerDFGToLLVM::compilePhantom): Deleted.
1307
1308 2015-04-28  Andreas Kling  <akling@apple.com>
1309
1310         DFG+FTL should generate efficient code for branching on a string's boolean value.
1311         <https://webkit.org/b/144317>
1312
1313         Reviewed by Geoff Garen & Filip Pizlo
1314
1315         Teach Branch nodes about StringUse and have them generate an efficient zero-length string check
1316         instead of dropping out to C++ whenever we branch on a string.
1317
1318         The FTL JIT already handled Branch nodes with StringUse through its use of boolify(), so only
1319         the DFG JIT gets some new codegen logic in this patch.
1320
1321         Test: js/regress/branch-on-string-as-boolean.js (~4.5x speedup)
1322
1323         * dfg/DFGFixupPhase.cpp:
1324         (JSC::DFG::FixupPhase::fixupNode):
1325         * dfg/DFGSpeculativeJIT.cpp:
1326         (JSC::DFG::SpeculativeJIT::emitStringBranch):
1327         * dfg/DFGSpeculativeJIT.h:
1328         * dfg/DFGSpeculativeJIT32_64.cpp:
1329         (JSC::DFG::SpeculativeJIT::emitBranch):
1330         * dfg/DFGSpeculativeJIT64.cpp:
1331         (JSC::DFG::SpeculativeJIT::emitBranch):
1332
1333 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
1334
1335         VarargsForwardingPhase should only consider MovHints that have the candidate as a child
1336         https://bugs.webkit.org/show_bug.cgi?id=144340
1337
1338         Reviewed by Michael Saboff and Mark Lam.
1339         
1340         Since we were considering all MovHints, we'd assume that the CreateDirectArguments or
1341         CreateClosedArguments node was live so long as any MovHinted bytecode variable was alive.
1342         Basically, we'd keep it alive until the end of the block. This maximized the chances of
1343         there being an interfering operation, which would prevent elimination.
1344         
1345         The fix is to only consider MovHints that have the arguments candidate as a child. We only
1346         care to track the liveness of those bytecode locals that would need an arguments object
1347         recovery on OSR exit.
1348         
1349         This is a speed-up on V8Spider/raytrace and Octane/raytrace because it undoes the regression
1350         introduced in http://trac.webkit.org/changeset/183406.
1351
1352         * dfg/DFGVarargsForwardingPhase.cpp:
1353
1354 2015-04-28  Csaba Osztrogonác  <ossy@webkit.org>
1355
1356         Remove WinCE cruft from cmake build system
1357         https://bugs.webkit.org/show_bug.cgi?id=144325
1358
1359         Reviewed by Gyuyoung Kim.
1360
1361         * CMakeLists.txt:
1362         * create_jit_stubs: Removed.
1363
1364 2015-04-27  Andreas Kling  <akling@apple.com>
1365
1366         RegExp matches arrays should use contiguous indexing.
1367         <https://webkit.org/b/144286>
1368
1369         Reviewed by Geoffrey Garen.
1370
1371         We had a custom Structure being used for RegExp matches arrays that would
1372         put the arrays into SlowPutArrayStorageShape mode. This was just left
1373         from when matches arrays were custom, lazily initialized objects.
1374
1375         This change removes that Structure and switches the matches arrays to
1376         using the default ContiguousShape Structure. This allows the FTL JIT
1377         to compile the inner loop of the Octane/regexp benchmark.
1378
1379         Also made a version of initializeIndex() [inline] that takes the indexing
1380         type in an argument, allowing createRegExpMatchesArray() to initialize
1381         the entire array without branching on the indexing type for each entry.
1382
1383         ~3% progression on Octane/regexp.
1384
1385         * runtime/JSGlobalObject.cpp:
1386         (JSC::JSGlobalObject::init):
1387         (JSC::JSGlobalObject::visitChildren):
1388         * runtime/JSGlobalObject.h:
1389         (JSC::JSGlobalObject::mapStructure):
1390         (JSC::JSGlobalObject::regExpMatchesArrayStructure): Deleted.
1391         * runtime/JSObject.h:
1392         (JSC::JSObject::initializeIndex):
1393         * runtime/RegExpMatchesArray.cpp:
1394         (JSC::createRegExpMatchesArray):
1395
1396 2015-04-27  Filip Pizlo  <fpizlo@apple.com>
1397
1398         FTL failed to initialize arguments.callee on the slow path as well as the fast path
1399         https://bugs.webkit.org/show_bug.cgi?id=144293
1400
1401         Reviewed by Mark Lam.
1402         
1403         The slow path doesn't fully initialize DirectArguments - it leaves callee blank. So, we need
1404         to initialize the callee on the common path after the fast and slow path.
1405
1406         * ftl/FTLLowerDFGToLLVM.cpp:
1407         (JSC::FTL::LowerDFGToLLVM::compileCreateDirectArguments):
1408         * tests/stress/arguments-callee-uninitialized.js: Added.
1409         (foo):
1410
1411 2015-04-27  Benjamin Poulain  <bpoulain@apple.com>
1412
1413         [JSC] Add support for typed arrays to the Array profiling
1414         https://bugs.webkit.org/show_bug.cgi?id=143913
1415
1416         Reviewed by Filip Pizlo.
1417
1418         This patch adds ArrayModes for every typed arrays. Having that information
1419         let us generate better GetByVal and PutByVal when the type speculation
1420         are not good enough.
1421
1422         A typical case where this is useful is any basic block for which the type
1423         of the object is always more restrictive than the speculation (for example, 
1424         a basic block gated by a branch only taken for on type).
1425
1426         * bytecode/ArrayProfile.cpp:
1427         (JSC::dumpArrayModes):
1428         * bytecode/ArrayProfile.h:
1429         (JSC::arrayModeFromStructure):
1430         * dfg/DFGArrayMode.cpp:
1431         (JSC::DFG::ArrayMode::fromObserved):
1432         (JSC::DFG::ArrayMode::refine):
1433         Maintain the refine() semantic. We do not support OutOfBounds access
1434         for GetByVal on typed array.
1435
1436         * runtime/IndexingType.h:
1437         * tests/stress/typed-array-get-by-val-profiling.js: Added.
1438         (testArray.testCode):
1439         (testArray):
1440         * tests/stress/typed-array-put-by-val-profiling.js: Added.
1441         (testArray.testCode):
1442         (testArray):
1443
1444 2015-04-27  Filip Pizlo  <fpizlo@apple.com>
1445
1446         Unreviewed, roll out r183438 "RegExp matches arrays should use contiguous indexing". It
1447         causes many debug test failures.
1448
1449         * runtime/JSGlobalObject.cpp:
1450         (JSC::JSGlobalObject::init):
1451         (JSC::JSGlobalObject::visitChildren):
1452         * runtime/JSGlobalObject.h:
1453         (JSC::JSGlobalObject::regExpMatchesArrayStructure):
1454         * runtime/JSObject.h:
1455         (JSC::JSObject::initializeIndex):
1456         * runtime/RegExpMatchesArray.cpp:
1457         (JSC::createRegExpMatchesArray):
1458
1459 2015-04-27  Andreas Kling  <akling@apple.com>
1460
1461         RegExp matches arrays should use contiguous indexing.
1462         <https://webkit.org/b/144286>
1463
1464         Reviewed by Geoffrey Garen.
1465
1466         We had a custom Structure being used for RegExp matches arrays that would
1467         put the arrays into SlowPutArrayStorageShape mode. This was just left
1468         from when matches arrays were custom, lazily initialized objects.
1469
1470         This change removes that Structure and switches the matches arrays to
1471         using the default ContiguousShape Structure. This allows the FTL JIT
1472         to compile the inner loop of the Octane/regexp benchmark.
1473
1474         Also made a version of initializeIndex() [inline] that takes the indexing
1475         type in an argument, allowing createRegExpMatchesArray() to initialize
1476         the entire array without branching on the indexing type for each entry.
1477
1478         ~3% progression on Octane/regexp.
1479
1480         * runtime/JSGlobalObject.cpp:
1481         (JSC::JSGlobalObject::init):
1482         (JSC::JSGlobalObject::visitChildren):
1483         * runtime/JSGlobalObject.h:
1484         (JSC::JSGlobalObject::mapStructure):
1485         (JSC::JSGlobalObject::regExpMatchesArrayStructure): Deleted.
1486         * runtime/JSObject.h:
1487         (JSC::JSObject::initializeIndex):
1488         * runtime/RegExpMatchesArray.cpp:
1489         (JSC::createRegExpMatchesArray):
1490
1491 2015-04-27  Ryosuke Niwa  <rniwa@webkit.org>
1492
1493         REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
1494         https://bugs.webkit.org/show_bug.cgi?id=144257
1495
1496         Temporarily disable skip these tests.
1497
1498         * tests/stress/template-literal-line-terminators.js:
1499         * tests/stress/template-literal-syntax.js:
1500         * tests/stress/template-literal.js:
1501
1502 2015-04-27  Basile Clement  <basile_clement@apple.com>
1503
1504         Function allocations shouldn't sink through Put operations
1505         https://bugs.webkit.org/show_bug.cgi?id=144176
1506
1507         Reviewed by Filip Pizlo.
1508
1509         By design, we don't support function allocation sinking through any
1510         related operation ; however object allocation can sink through PutByOffset et
1511         al.
1512
1513         Currently, the checks to prevent function allocation to sink through
1514         these are misguided and do not prevent anything ; function allocation sinking
1515         through these operations is prevented as a side effect of requiring an
1516         AllocatePropertyStorage through which the function allocation is seen as
1517         escaping.
1518
1519         This changes it so that ObjectAllocationSinkingPhase::handleNode()
1520         checks properly that only object allocations sink through related write
1521         operations.
1522
1523         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1524         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
1525         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1526
1527 2015-04-25  Filip Pizlo  <fpizlo@apple.com>
1528
1529         VarargsForwardingPhase should use bytecode liveness in addition to other uses to determine the last point that a candidate is used
1530         https://bugs.webkit.org/show_bug.cgi?id=143843
1531
1532         Reviewed by Geoffrey Garen.
1533         
1534         It will soon come to pass that Phantom isn't available at the time that
1535         VarargsForwardingPhase runs. So, it needs to use some other mechanism for discovering when
1536         a value dies for OSR.
1537         
1538         This is simplified by two things:
1539         
1540         1) The bytecode kill analysis is now reusable. This patch makes it even more reusable than
1541            before by polishing the API.
1542         
1543         2) This phase already operates on one node at a time and allows itself to do a full search
1544            of the enclosing basic block for that node. This is fine because CreateDirectArguments
1545            and friends is a rarely occurring node. The fact that it operates on one node at a time
1546            makes it even easier to reason about OSR liveness - we just track the list of locals in
1547            which it is live.
1548         
1549         This change has no effect right now but it is a necessary prerequisite to implementing
1550         https://bugs.webkit.org/show_bug.cgi?id=143736.
1551
1552         * dfg/DFGBasicBlock.h:
1553         (JSC::DFG::BasicBlock::tryAt):
1554         * dfg/DFGForAllKills.h:
1555         (JSC::DFG::forAllKilledOperands):
1556         * dfg/DFGPhantomInsertionPhase.cpp:
1557         * dfg/DFGVarargsForwardingPhase.cpp:
1558
1559 2015-04-27  Jordan Harband  <ljharb@gmail.com>
1560
1561         Map#entries and Map#keys error for non-Maps is swapped
1562         https://bugs.webkit.org/show_bug.cgi?id=144253
1563
1564         Reviewed by Simon Fraser.
1565
1566         Correcting error messages on Set/Map methods when called on
1567         incompatible objects.
1568
1569         * runtime/MapPrototype.cpp:
1570         (JSC::mapProtoFuncEntries):
1571         (JSC::mapProtoFuncKeys):
1572         * runtime/SetPrototype.cpp:
1573         (JSC::setProtoFuncEntries):
1574
1575 2015-04-24  Filip Pizlo  <fpizlo@apple.com>
1576
1577         Rationalize DFG DCE handling of nodes that perform checks that propagate through AI
1578         https://bugs.webkit.org/show_bug.cgi?id=144186
1579
1580         Reviewed by Geoffrey Garen.
1581         
1582         If I do ArithAdd(Int32Use, Int32Use, CheckOverflow) then AI will prove that this returns
1583         Int32. We may later perform code simplifications based on the proof that this is Int32, and
1584         we may kill all DFG users of this ArithAdd. Then we may prove that there is no exit site at
1585         which the ArithAdd is live. This seems like it is sufficient to then kill the ArithAdd,
1586         except that we still need the overflow check!
1587
1588         Previously we mishandled this:
1589
1590         - In places where we want the overflow check we need to use MustGenerate(@ArithAdd) as a hack
1591           to keep it alive. That's dirty and it's just indicative of a deeper issue.
1592
1593         - Our MovHint removal doesn't do Phantom canonicalization which essentially makes it
1594           powerless. This was sort of hiding the bug.
1595
1596         - Nodes that have checks that AI leverages should always be NodeMustGenerate. You can't kill
1597           something that you are relying on for subsequent simplifications.
1598         
1599         This fixes MovHint removal to also canonicalize Phantoms. This also adds ModeMustGenerate to
1600         nodes that may perform checks that are used by AI to guarantee the result type. As a result,
1601         we no longer need the weird MustGenerate node.
1602
1603         * dfg/DFGAbstractInterpreterInlines.h:
1604         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1605         * dfg/DFGArgumentsEliminationPhase.cpp:
1606         * dfg/DFGClobberize.h:
1607         (JSC::DFG::clobberize):
1608         * dfg/DFGDCEPhase.cpp:
1609         (JSC::DFG::DCEPhase::run):
1610         * dfg/DFGDoesGC.cpp:
1611         (JSC::DFG::doesGC):
1612         * dfg/DFGFixupPhase.cpp:
1613         (JSC::DFG::FixupPhase::fixupNode):
1614         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
1615         * dfg/DFGIntegerCheckCombiningPhase.cpp:
1616         (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
1617         (JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd): Deleted.
1618         * dfg/DFGMayExit.cpp:
1619         (JSC::DFG::mayExit):
1620         * dfg/DFGNode.h:
1621         (JSC::DFG::Node::willHaveCodeGenOrOSR):
1622         * dfg/DFGNodeType.h:
1623         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1624         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1625         * dfg/DFGPhantomCanonicalizationPhase.cpp:
1626         (JSC::DFG::PhantomCanonicalizationPhase::run):
1627         * dfg/DFGPhantomRemovalPhase.cpp:
1628         (JSC::DFG::PhantomRemovalPhase::run):
1629         * dfg/DFGPlan.cpp:
1630         (JSC::DFG::Plan::compileInThreadImpl):
1631         * dfg/DFGPredictionPropagationPhase.cpp:
1632         (JSC::DFG::PredictionPropagationPhase::propagate):
1633         * dfg/DFGSafeToExecute.h:
1634         (JSC::DFG::safeToExecute):
1635         * dfg/DFGSpeculativeJIT32_64.cpp:
1636         (JSC::DFG::SpeculativeJIT::compile):
1637         * dfg/DFGSpeculativeJIT64.cpp:
1638         (JSC::DFG::SpeculativeJIT::compile):
1639         * dfg/DFGTypeCheckHoistingPhase.cpp:
1640         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
1641         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
1642         * dfg/DFGVarargsForwardingPhase.cpp:
1643         * ftl/FTLCapabilities.cpp:
1644         (JSC::FTL::canCompile):
1645         * ftl/FTLLowerDFGToLLVM.cpp:
1646         (JSC::FTL::LowerDFGToLLVM::compileNode):
1647         * tests/stress/fold-based-on-int32-proof-mul-branch.js: Added.
1648         (foo):
1649         * tests/stress/fold-based-on-int32-proof-mul.js: Added.
1650         (foo):
1651         * tests/stress/fold-based-on-int32-proof-or-zero.js: Added.
1652         (foo):
1653         * tests/stress/fold-based-on-int32-proof.js: Added.
1654         (foo):
1655
1656 2015-04-26  Ryosuke Niwa  <rniwa@webkit.org>
1657
1658         Class body ending with a semicolon throws a SyntaxError
1659         https://bugs.webkit.org/show_bug.cgi?id=144244
1660
1661         Reviewed by Darin Adler.
1662
1663         The bug was caused by parseClass's inner loop for method definitions not moving onto the next iteration
1664         it encounters a semicolon. As a result, we always expected a method to appear after a semicolon. Fixed
1665         it by continue'ing when it encounters a semicolon.
1666
1667         * parser/Parser.cpp:
1668         (JSC::Parser<LexerType>::parseClass):
1669
1670 2015-04-26  Ryosuke Niwa  <rniwa@webkit.org>
1671
1672         Getter or setter method named "prototype" or "constrcutor" should throw SyntaxError
1673         https://bugs.webkit.org/show_bug.cgi?id=144243
1674
1675         Reviewed by Darin Adler.
1676
1677         Fixed the bug by adding explicit checks in parseGetterSetter when we're parsing class methods.
1678
1679         * parser/Parser.cpp:
1680         (JSC::Parser<LexerType>::parseGetterSetter):
1681
1682 2015-04-26  Jordan Harband  <ljharb@gmail.com>
1683
1684         Map#forEach does not pass "map" argument to callback.
1685         https://bugs.webkit.org/show_bug.cgi?id=144187
1686
1687         Reviewed by Darin Adler.
1688
1689         Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-map.prototype.foreach
1690         step 7.a.i., the callback should be called with three arguments.
1691
1692         * runtime/MapPrototype.cpp:
1693         (JSC::mapProtoFuncForEach):
1694
1695 2015-04-26  Yusuke Suzuki  <utatane.tea@gmail.com>
1696
1697         [ES6] Implement ES6 template literals
1698         https://bugs.webkit.org/show_bug.cgi?id=142691
1699
1700         Reviewed by Darin Adler.
1701
1702         This patch implements TemplateLiteral.
1703         Since TaggedTemplate requires some global states and
1704         primitive operations like GetTemplateObject,
1705         we separate the patch. It will be implemented in a subsequent patch.
1706
1707         Template Literal Syntax is guarded by ENABLE_ES6_TEMPLATE_LITERAL_SYNTAX compile time flag.
1708         By disabling it, we can disable Template Literal support.
1709
1710         To implement template literals, in this patch,
1711         we newly introduces bytecode op_to_string.
1712         In template literals, we alternately evaluate the expression and
1713         perform ToString onto the result of evaluation.
1714         For example,
1715
1716         `${f1()} ${f2()}`
1717
1718         In this template literal, execution order is the following,
1719         1. calling f1()
1720         2. ToString(the result of f1())
1721         3. calling f2()
1722         4. ToString(the result of f2())
1723
1724         op_strcat also performs ToString. However, performing ToString
1725         onto expressions are batched in op_strcat, it's not the same to the
1726         template literal spec. In the above example,
1727         ToString(f1()) should be called before calling f2().
1728
1729         * Configurations/FeatureDefines.xcconfig:
1730         * bytecode/BytecodeList.json:
1731         * bytecode/BytecodeUseDef.h:
1732         (JSC::computeUsesForBytecodeOffset):
1733         (JSC::computeDefsForBytecodeOffset):
1734         * bytecode/CodeBlock.cpp:
1735         (JSC::CodeBlock::dumpBytecode):
1736         * bytecompiler/BytecodeGenerator.h:
1737         (JSC::BytecodeGenerator::emitToString):
1738         (JSC::BytecodeGenerator::emitToNumber): Deleted.
1739         * bytecompiler/NodesCodegen.cpp:
1740         (JSC::TemplateStringNode::emitBytecode):
1741         (JSC::TemplateLiteralNode::emitBytecode):
1742         * dfg/DFGByteCodeParser.cpp:
1743         (JSC::DFG::ByteCodeParser::parseBlock):
1744         * dfg/DFGCapabilities.cpp:
1745         (JSC::DFG::capabilityLevel):
1746         * jit/JIT.cpp:
1747         (JSC::JIT::privateCompileMainPass):
1748         (JSC::JIT::privateCompileSlowCases):
1749         * jit/JIT.h:
1750         * jit/JITOpcodes.cpp:
1751         (JSC::JIT::emit_op_to_string):
1752         (JSC::JIT::emitSlow_op_to_string):
1753         * jit/JITOpcodes32_64.cpp:
1754         (JSC::JIT::emit_op_to_string):
1755         (JSC::JIT::emitSlow_op_to_string):
1756         * llint/LowLevelInterpreter32_64.asm:
1757         * llint/LowLevelInterpreter64.asm:
1758         * parser/ASTBuilder.h:
1759         (JSC::ASTBuilder::createTemplateString):
1760         (JSC::ASTBuilder::createTemplateStringList):
1761         (JSC::ASTBuilder::createTemplateExpressionList):
1762         (JSC::ASTBuilder::createTemplateLiteral):
1763         * parser/Lexer.cpp:
1764         (JSC::Lexer<T>::Lexer):
1765         (JSC::Lexer<T>::parseIdentifierSlowCase):
1766         (JSC::Lexer<T>::parseString):
1767         (JSC::LineNumberAdder::LineNumberAdder):
1768         (JSC::LineNumberAdder::clear):
1769         (JSC::LineNumberAdder::add):
1770         (JSC::Lexer<T>::parseTemplateLiteral):
1771         (JSC::Lexer<T>::lex):
1772         (JSC::Lexer<T>::scanRegExp):
1773         (JSC::Lexer<T>::scanTrailingTemplateString):
1774         (JSC::Lexer<T>::parseStringSlowCase): Deleted.
1775         * parser/Lexer.h:
1776         * parser/NodeConstructors.h:
1777         (JSC::TemplateExpressionListNode::TemplateExpressionListNode):
1778         (JSC::TemplateStringNode::TemplateStringNode):
1779         (JSC::TemplateStringListNode::TemplateStringListNode):
1780         (JSC::TemplateLiteralNode::TemplateLiteralNode):
1781         * parser/Nodes.h:
1782         (JSC::TemplateExpressionListNode::value):
1783         (JSC::TemplateExpressionListNode::next):
1784         (JSC::TemplateStringNode::cooked):
1785         (JSC::TemplateStringNode::raw):
1786         (JSC::TemplateStringListNode::value):
1787         (JSC::TemplateStringListNode::next):
1788         * parser/Parser.cpp:
1789         (JSC::Parser<LexerType>::parseTemplateString):
1790         (JSC::Parser<LexerType>::parseTemplateLiteral):
1791         (JSC::Parser<LexerType>::parsePrimaryExpression):
1792         * parser/Parser.h:
1793         * parser/ParserTokens.h:
1794         * parser/SyntaxChecker.h:
1795         (JSC::SyntaxChecker::createTemplateString):
1796         (JSC::SyntaxChecker::createTemplateStringList):
1797         (JSC::SyntaxChecker::createTemplateExpressionList):
1798         (JSC::SyntaxChecker::createTemplateLiteral):
1799         (JSC::SyntaxChecker::createSpreadExpression): Deleted.
1800         * runtime/CommonSlowPaths.cpp:
1801         (JSC::SLOW_PATH_DECL):
1802         * runtime/CommonSlowPaths.h:
1803         * tests/stress/template-literal-line-terminators.js: Added.
1804         (test):
1805         (testEval):
1806         (testEvalLineNumber):
1807         * tests/stress/template-literal-syntax.js: Added.
1808         (testSyntax):
1809         (testSyntaxError):
1810         * tests/stress/template-literal.js: Added.
1811         (test):
1812         (testEval):
1813         (testEmbedded):
1814
1815 2015-04-26  Jordan Harband  <ljharb@gmail.com>
1816
1817         Set#forEach does not pass "key" or "set" arguments to callback.
1818         https://bugs.webkit.org/show_bug.cgi?id=144188
1819
1820         Reviewed by Darin Adler.
1821
1822         Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype.foreach
1823         Set#forEach should pass 3 arguments to the callback.
1824
1825         * runtime/SetPrototype.cpp:
1826         (JSC::setProtoFuncForEach):
1827
1828 2015-04-26  Benjamin Poulain  <benjamin@webkit.org>
1829
1830         [JSC] Implement Math.clz32(), remove Number.clz()
1831         https://bugs.webkit.org/show_bug.cgi?id=144205
1832
1833         Reviewed by Michael Saboff.
1834
1835         This patch adds the ES6 function Math.clz32(), and remove the non-standard
1836         Number.clz(). Number.clz() probably came from an older draft.
1837
1838         The new function has a corresponding instrinsic: Clz32Intrinsic,
1839         and a corresponding DFG node: ArithClz32, optimized all the way to LLVM.
1840
1841         * assembler/MacroAssemblerX86Common.h:
1842         (JSC::MacroAssemblerX86Common::countLeadingZeros32):
1843         * assembler/X86Assembler.h:
1844         (JSC::X86Assembler::bsr_rr):
1845         The x86 assembler did not have countLeadingZeros32() because there is
1846         no native CLZ instruction on that architecture.
1847
1848         I have added the version with bsr + branches for the case of zero.
1849         An other popular version uses cmov to handle the case of zero. I kept
1850         it simple since the Assembler has no support for cmov.
1851
1852         It is unlikely to matter much. If the code is hot enough, LLVM picks
1853         something good based on the surrounding code.
1854
1855         * dfg/DFGAbstractInterpreterInlines.h:
1856         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1857         Constant handling + effect propagation. The node only produces integer (between 0 and 32).
1858
1859         * dfg/DFGBackwardsPropagationPhase.cpp:
1860         (JSC::DFG::BackwardsPropagationPhase::propagate):
1861         Thanks to the definition of toUint32(), we can ignore plenty of details
1862         from doubles.
1863
1864         * dfg/DFGByteCodeParser.cpp:
1865         (JSC::DFG::ByteCodeParser::handleIntrinsic):
1866         * dfg/DFGClobberize.h:
1867         (JSC::DFG::clobberize):
1868         * dfg/DFGDoesGC.cpp:
1869         (JSC::DFG::doesGC):
1870         * dfg/DFGFixupPhase.cpp:
1871         (JSC::DFG::FixupPhase::fixupNode):
1872         * dfg/DFGNodeType.h:
1873         * dfg/DFGPredictionPropagationPhase.cpp:
1874         (JSC::DFG::PredictionPropagationPhase::propagate):
1875         * dfg/DFGSafeToExecute.h:
1876         (JSC::DFG::safeToExecute):
1877         * dfg/DFGSpeculativeJIT.cpp:
1878         (JSC::DFG::SpeculativeJIT::compileArithClz32):
1879         * dfg/DFGSpeculativeJIT.h:
1880         * dfg/DFGSpeculativeJIT32_64.cpp:
1881         (JSC::DFG::SpeculativeJIT::compile):
1882         * dfg/DFGSpeculativeJIT64.cpp:
1883         (JSC::DFG::SpeculativeJIT::compile):
1884         * ftl/FTLCapabilities.cpp:
1885         (JSC::FTL::canCompile):
1886         * ftl/FTLIntrinsicRepository.h:
1887         * ftl/FTLLowerDFGToLLVM.cpp:
1888         (JSC::FTL::LowerDFGToLLVM::compileNode):
1889         (JSC::FTL::LowerDFGToLLVM::compileArithClz32):
1890         * ftl/FTLOutput.h:
1891         (JSC::FTL::Output::ctlz32):
1892         * jit/ThunkGenerators.cpp:
1893         (JSC::clz32ThunkGenerator):
1894         * jit/ThunkGenerators.h:
1895         * runtime/Intrinsic.h:
1896         * runtime/MathCommon.h:
1897         (JSC::clz32):
1898         Fun fact: InstCombine does not recognize this pattern to eliminate
1899         the branch which makes our FTL version better than the C version.
1900
1901         * runtime/MathObject.cpp:
1902         (JSC::MathObject::finishCreation):
1903         (JSC::mathProtoFuncClz32):
1904         * runtime/NumberPrototype.cpp:
1905         (JSC::clz): Deleted.
1906         (JSC::numberProtoFuncClz): Deleted.
1907         * runtime/VM.cpp:
1908         (JSC::thunkGeneratorForIntrinsic):
1909         * tests/stress/math-clz32-basics.js: Added.
1910         (mathClz32OnInteger):
1911         (testMathClz32OnIntegers):
1912         (verifyMathClz32OnIntegerWithOtherTypes):
1913         (mathClz32OnDouble):
1914         (testMathClz32OnDoubles):
1915         (verifyMathClz32OnDoublesWithOtherTypes):
1916         (mathClz32NoArguments):
1917         (mathClz32TooManyArguments):
1918         (testMathClz32OnConstants):
1919         (mathClz32StructTransition):
1920         (Math.clz32):
1921
1922 2015-04-26  Yusuke Suzuki  <utatane.tea@gmail.com>
1923
1924         [ES6] Array.from need to accept iterables
1925         https://bugs.webkit.org/show_bug.cgi?id=141055
1926
1927         Reviewed by Darin Adler.
1928
1929         ES6 spec requires that Array.from accepts iterable objects.
1930         This patch introduces this functionality, Array.from accepting iterable objects.
1931
1932         Currently, `isConstructor` is not used. Instead of it, `typeof thiObj === "function"` is used.
1933         However, it doesn't conform to the spec. While `isConstructor` queries the given object has `[[Construct]]`,
1934         `typeof thisObj === "function"` queries the given object has `[[Call]]`.
1935         This will be fixed in the subsequent patch[1].
1936
1937         [1]: https://bugs.webkit.org/show_bug.cgi?id=144093
1938
1939         * builtins/ArrayConstructor.js:
1940         (from):
1941         * parser/Parser.cpp:
1942         (JSC::Parser<LexerType>::parseInner):
1943         * runtime/CommonIdentifiers.h:
1944         * runtime/JSGlobalObject.cpp:
1945         (JSC::JSGlobalObject::init):
1946         * tests/stress/array-from-with-iterable.js: Added.
1947         (shouldBe):
1948         (.set for):
1949         (.set var):
1950         (.get var):
1951         (argumentsGenerators):
1952         (.set shouldBe):
1953         (.set new):
1954         * tests/stress/array-from-with-iterator.js: Added.
1955         (shouldBe):
1956         (shouldThrow):
1957         (createIterator.iterator.return):
1958         (createIterator):
1959         (.):
1960
1961 2015-04-25  Jordan Harband  <ljharb@gmail.com>
1962
1963         Set#keys !== Set#values
1964         https://bugs.webkit.org/show_bug.cgi?id=144190
1965
1966         Reviewed by Darin Adler.
1967
1968         per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype.keys
1969         Set#keys should === Set#values
1970
1971         * runtime/SetPrototype.cpp:
1972         (JSC::SetPrototype::finishCreation):
1973         (JSC::setProtoFuncValues):
1974         (JSC::setProtoFuncEntries):
1975         (JSC::setProtoFuncKeys): Deleted.
1976
1977 2015-04-25  Joseph Pecoraro  <pecoraro@apple.com>
1978
1979         Allow for pausing a JSContext when opening a Web Inspector
1980         <rdar://problem/20564788>
1981
1982         Reviewed by Timothy Hatcher.
1983
1984         * inspector/remote/RemoteInspector.mm:
1985         (Inspector::RemoteInspector::receivedSetupMessage):
1986         * inspector/remote/RemoteInspectorConstants.h:
1987         * inspector/remote/RemoteInspectorDebuggable.h:
1988         * inspector/remote/RemoteInspectorDebuggableConnection.h:
1989         * inspector/remote/RemoteInspectorDebuggableConnection.mm:
1990         (Inspector::RemoteInspectorDebuggableConnection::setup):
1991         On any incoming setup message, we may want to automatically
1992         pause the debuggable. If requested, pause the debuggable
1993         after we have setup the frontend connection.
1994
1995         * runtime/JSGlobalObjectDebuggable.h:
1996         * runtime/JSGlobalObjectDebuggable.cpp:
1997         (JSC::JSGlobalObjectDebuggable::pause):
1998         Pass through to the inspector controller.
1999
2000         * inspector/JSGlobalObjectInspectorController.h:
2001         * inspector/JSGlobalObjectInspectorController.cpp:
2002         (Inspector::JSGlobalObjectInspectorController::pause):
2003         Enable pause on next statement.
2004
2005 2015-04-23  Ryosuke Niwa  <rniwa@webkit.org>
2006
2007         class methods should be non-enumerable
2008         https://bugs.webkit.org/show_bug.cgi?id=143181
2009
2010         Reviewed by Darin Adler.
2011
2012         Fixed the bug by using Object.defineProperty to define methods.
2013
2014         This patch adds the concept of link time constants and uses it to resolve Object.defineProperty
2015         inside CodeBlock's constructor since bytecode can be linked against multiple global objects.
2016
2017         * bytecode/CodeBlock.cpp: 
2018         (JSC::CodeBlock::CodeBlock): Resolve link time constants that are used. Ignore ones with register
2019         index of zero.
2020         * bytecode/SpecialPointer.h: Added a new enum for link time constants. It currently contains
2021         exactly one entry for Object.defineProperty.
2022         * bytecode/UnlinkedCodeBlock.h:
2023         (JSC::UnlinkedCodeBlock::addConstant): Added. Like addConstant that takes JSValue, allocate a new
2024         constant register for the link time constant we're adding.
2025         (JSC::UnlinkedCodeBlock::registerIndexForLinkTimeConstant): Added.
2026         * bytecompiler/BytecodeGenerator.cpp:
2027         (JSC::BytecodeGenerator::emitMoveLinkTimeConstant): Added. Like addConstantValue, allocate a new
2028         register for the specified link time constant and notify UnlinkedCodeBlock about it.
2029         (JSC::BytecodeGenerator::emitCallDefineProperty): Added. Create a new property descriptor and call
2030         Object.defineProperty with it.
2031         * bytecompiler/BytecodeGenerator.h:
2032         * bytecompiler/NodesCodegen.cpp:
2033         (JSC::PropertyListNode::emitBytecode): Make static and non-static getters and setters for classes
2034         non-enumerable by using emitCallDefineProperty to define them.
2035         (JSC::PropertyListNode::emitPutConstantProperty): Ditto for a non-accessor properties.
2036         (JSC::ClassExprNode::emitBytecode): Make prototype.constructor non-enumerable and make prototype
2037         property on the class non-writable, non-configurable, and non-enumerable by using defineProperty.
2038         * runtime/CommonIdentifiers.h:
2039         * runtime/JSGlobalObject.cpp:
2040         (JSC::JSGlobalObject::init): Set m_definePropertyFunction.
2041         (JSC::JSGlobalObject::visitChildren): Visit m_definePropertyFunction.
2042         * runtime/JSGlobalObject.h:
2043         (JSC::JSGlobalObject::definePropertyFunction): Added.
2044         (JSC::JSGlobalObject::actualPointerFor): Added a variant that takes LinkTimeConstant.
2045         (JSC::JSGlobalObject::jsCellForLinkTimeConstant): Like actualPointerFor, takes LinkTimeConstant and
2046         returns a JSCell; e.g. Object.defineProperty.
2047         * runtime/ObjectConstructor.cpp:
2048         (JSC::ObjectConstructor::addDefineProperty): Added. Returns Object.defineProperty.
2049         * runtime/ObjectConstructor.h:
2050
2051 2015-04-25  Yusuke Suzuki  <utatane.tea@gmail.com>
2052
2053         [ES6] Implement String.fromCodePoint
2054         https://bugs.webkit.org/show_bug.cgi?id=144160
2055
2056         Reviewed by Darin Adler.
2057
2058         This patch implements String.fromCodePoint.
2059         It accepts multiple code points and generates a string that consists of given code points.
2060         The range [0x0000 - 0x10FFFF] is valid for code points.
2061         If the given value is out of range, throw a range error.
2062
2063         When a 0xFFFF <= valid code point is given,
2064         String.fromCodePoint generates a string that contains surrogate pairs.
2065
2066         * runtime/StringConstructor.cpp:
2067         (JSC::stringFromCodePoint):
2068         (JSC::constructWithStringConstructor):
2069         * tests/stress/string-from-code-point.js: Added.
2070         (shouldBe):
2071         (shouldThrow):
2072         (toCodePoints):
2073         (passThrough):
2074
2075 2015-04-25  Martin Robinson  <mrobinson@igalia.com>
2076
2077         Rename ENABLE_3D_RENDERING to ENABLE_3D_TRANSFORMS
2078         https://bugs.webkit.org/show_bug.cgi?id=144182
2079
2080         Reviewed by Simon Fraser.
2081
2082         * Configurations/FeatureDefines.xcconfig: Replace all instances of 3D_RENDERING with 3D_TRANSFORMS.
2083
2084 2015-04-25  Mark Lam  <mark.lam@apple.com>
2085
2086         mayExit() is wrong about Branch nodes with ObjectOrOtherUse: they can exit.
2087         https://bugs.webkit.org/show_bug.cgi?id=144152
2088
2089         Reviewed by Filip Pizlo.
2090
2091         Changed the EdgeMayExit functor to recognize ObjectUse, ObjectOrOtherUse,
2092         StringObjectUse, and StringOrStringObjectUse kinds as potentially triggering
2093         OSR exits.  This was overlooked in the original code.
2094
2095         While only the ObjectOrOtherUse kind is relevant for manifesting this bug with
2096         the Branch node, the other 3 may also trigger the same bug for other nodes.
2097         To prevent this bug from manifesting with other nodes (and future ones that
2098         are yet to be added to mayExits()'s "potential won't exit" set), we fix the
2099         EdgeMayExit functor to handle all 4 use kinds (instead of just ObjectOrOtherUse).
2100
2101         Also added a test to exercise a code path that will trigger this bug with
2102         the Branch node before the fix is applied.
2103
2104         * dfg/DFGMayExit.cpp:
2105         * tests/stress/branch-may-exit-due-to-object-or-other-use-kind.js: Added.
2106         (inlinedFunction):
2107         (foo):
2108
2109 2015-04-24  Commit Queue  <commit-queue@webkit.org>
2110
2111         Unreviewed, rolling out r183288.
2112         https://bugs.webkit.org/show_bug.cgi?id=144189
2113
2114         Made js/sort-with-side-effecting-comparisons.html time out in
2115         debug builds (Requested by ap on #webkit).
2116
2117         Reverted changeset:
2118
2119         "It shouldn't take 1846 lines of code and 5 FIXMEs to sort an
2120         array."
2121         https://bugs.webkit.org/show_bug.cgi?id=144013
2122         http://trac.webkit.org/changeset/183288
2123
2124 2015-04-24  Filip Pizlo  <fpizlo@apple.com>
2125
2126         CRASH in operationCreateDirectArgumentsDuringExit()
2127         https://bugs.webkit.org/show_bug.cgi?id=143962
2128
2129         Reviewed by Geoffrey Garen.
2130         
2131         We shouldn't assume that constant-like OSR exit values are always recoverable. They are only
2132         recoverable so long as they are live. Therefore, OSR exit should track liveness of
2133         constants instead of assuming that they are always live.
2134
2135         * dfg/DFGGenerationInfo.h:
2136         (JSC::DFG::GenerationInfo::noticeOSRBirth):
2137         (JSC::DFG::GenerationInfo::appendBirth):
2138         * dfg/DFGSpeculativeJIT.cpp:
2139         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2140         * dfg/DFGVariableEvent.cpp:
2141         (JSC::DFG::VariableEvent::dump):
2142         * dfg/DFGVariableEvent.h:
2143         (JSC::DFG::VariableEvent::birth):
2144         (JSC::DFG::VariableEvent::id):
2145         (JSC::DFG::VariableEvent::dataFormat):
2146         * dfg/DFGVariableEventStream.cpp:
2147         (JSC::DFG::VariableEventStream::reconstruct):
2148         * tests/stress/phantom-direct-arguments-clobber-argument-count.js: Added.
2149         (foo):
2150         (bar):
2151         * tests/stress/phantom-direct-arguments-clobber-callee.js: Added.
2152         (foo):
2153         (bar):
2154
2155 2015-04-24  Benjamin Poulain  <bpoulain@apple.com>
2156
2157         [JSC] When inserting a NaN into a Int32 array, we convert it to DoubleArray then to ContiguousArray
2158         https://bugs.webkit.org/show_bug.cgi?id=144169
2159
2160         Reviewed by Geoffrey Garen.
2161
2162         * runtime/JSObject.cpp:
2163         (JSC::JSObject::convertInt32ForValue):
2164         DoubleArray do not store NaN, they are used for holes.
2165         What happened was:
2166         1) We fail to insert the NaN in the Int32 array because it is a double.
2167         2) We were converting the array to DoubleArray.
2168         3) We were trying to insert the value again. We would fail again because
2169            DoubleArray does not store NaN.
2170         4) We would convert the DoubleArrayt to Contiguous Array, converting the values
2171            to boxed values.
2172
2173         * tests/stress/int32array-transition-on-nan.js: Added.
2174         The behavior is not really observable. This only test nothing crashes in those
2175         cases.
2176
2177         (insertNaNWhileFilling):
2178         (testInsertNaNWhileFilling):
2179         (insertNaNAfterFilling):
2180         (testInsertNaNAfterFilling):
2181         (pushNaNWhileFilling):
2182         (testPushNaNWhileFilling):
2183
2184 2015-04-21  Geoffrey Garen  <ggaren@apple.com>
2185
2186         It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
2187         https://bugs.webkit.org/show_bug.cgi?id=144013
2188
2189         Reviewed by Mark Lam.
2190
2191         This patch implements Array.prototype.sort in JavaScript, removing the
2192         C++ implementations. It is simpler and less error-prone to express our
2193         operations in JavaScript, which provides memory safety, exception safety,
2194         and recursion safety.
2195
2196         The performance result is mixed, but net positive in my opinion. It's
2197         difficult to enumerate all the results, since we used to have so many
2198         different sorting modes, and there are lots of different data patterns
2199         across which you might want to measure sorting. Suffice it to say:
2200
2201             (*) The benchmarks we track are faster or unchanged.
2202
2203             (*) Sorting random input using a comparator -- which we think is
2204             common -- is 3X faster.
2205
2206             (*) Sorting random input in a non-array object -- which jQuery does
2207             -- is 4X faster.
2208
2209             (*) Sorting random input in a compact array of integers using a
2210             trivial pattern-matchable comparator is 2X *slower*.
2211
2212         * builtins/Array.prototype.js:
2213         (sort.min):
2214         (sort.stringComparator):
2215         (sort.compactSparse): Special case compaction for sparse arrays because
2216         we don't want to hang when sorting new Array(BIG).
2217
2218         (sort.compact):
2219         (sort.merge):
2220         (sort.mergeSort): Use merge sort because it's a reasonably efficient
2221         stable sort. We have evidence that some sites depend on stable sort,
2222         even though the ES6 spec does not mandate it. (See
2223         <http://trac.webkit.org/changeset/33967>.)
2224
2225         This is a textbook implementation of merge sort with three optimizations:
2226
2227             (1) Use iteration instead of recursion;
2228
2229             (2) Use array subscripting instead of array copying in order to
2230             create logical sub-lists without creating physical sub-lists;
2231
2232             (3) Swap src and dst at each iteration instead of copying src into
2233             dst, and only copy src into the subject array at the end if src is
2234             not the subject array.
2235
2236         (sort.inflate):
2237         (sort.comparatorSort):
2238         (sort): Sort in JavaScript for the win.
2239
2240         * builtins/BuiltinExecutables.cpp:
2241         (JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
2242         names so we can use helper functions.
2243
2244         * bytecode/CodeBlock.h:
2245         (JSC::CodeBlock::isNumericCompareFunction): Deleted.
2246         * bytecode/UnlinkedCodeBlock.cpp:
2247         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
2248         * bytecode/UnlinkedCodeBlock.h:
2249         (JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
2250         (JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
2251         * bytecompiler/BytecodeGenerator.cpp:
2252         (JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
2253         * bytecompiler/BytecodeGenerator.h:
2254         * bytecompiler/NodesCodegen.cpp:
2255         (JSC::FunctionNode::emitBytecode): We don't do this special casing based
2256         on pattern matching anymore. This was mainly an optimization to avoid 
2257         the overhead of calling from C++ to JS, which we now avoid by
2258         sorting in JS.
2259
2260         * heap/Heap.cpp:
2261         (JSC::Heap::markRoots):
2262         (JSC::Heap::pushTempSortVector): Deleted.
2263         (JSC::Heap::popTempSortVector): Deleted.
2264         (JSC::Heap::visitTempSortVectors): Deleted.
2265         * heap/Heap.h: We don't have temp sort vectors anymore because we sort
2266         in JavaScript using a normal JavaScript array for our temporary storage.
2267
2268         * parser/Parser.cpp:
2269         (JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
2270         helper functions.
2271
2272         * runtime/ArrayPrototype.cpp:
2273         (JSC::isNumericCompareFunction): Deleted.
2274         (JSC::attemptFastSort): Deleted.
2275         (JSC::performSlowSort): Deleted.
2276         (JSC::arrayProtoFuncSort): Deleted.
2277
2278         * runtime/CommonIdentifiers.h: New strings used by sort.
2279
2280         * runtime/JSArray.cpp:
2281         (JSC::compareNumbersForQSortWithInt32): Deleted.
2282         (JSC::compareNumbersForQSortWithDouble): Deleted.
2283         (JSC::compareNumbersForQSort): Deleted.
2284         (JSC::compareByStringPairForQSort): Deleted.
2285         (JSC::JSArray::sortNumericVector): Deleted.
2286         (JSC::JSArray::sortNumeric): Deleted.
2287         (JSC::ContiguousTypeAccessor::getAsValue): Deleted.
2288         (JSC::ContiguousTypeAccessor::setWithValue): Deleted.
2289         (JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
2290         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
2291         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
2292         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
2293         (JSC::JSArray::sortCompactedVector): Deleted.
2294         (JSC::JSArray::sort): Deleted.
2295         (JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
2296         (JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
2297         (JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
2298         (JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
2299         (JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
2300         (JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
2301         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
2302         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
2303         (JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
2304         (JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
2305         (JSC::JSArray::sortVector): Deleted.
2306         (JSC::JSArray::compactForSorting): Deleted.
2307         * runtime/JSArray.h:
2308
2309         * runtime/JSGlobalObject.cpp:
2310         (JSC::JSGlobalObject::init):
2311         * runtime/ObjectConstructor.cpp:
2312         (JSC::ObjectConstructor::finishCreation): Provide some builtins used
2313         by sort.
2314
2315 2015-04-24  Matthew Mirman  <mmirman@apple.com>
2316
2317         Made Object.prototype.__proto__ native getter and setter check that this object not null or undefined
2318         https://bugs.webkit.org/show_bug.cgi?id=141865
2319         rdar://problem/19927273
2320
2321         Reviewed by Filip Pizlo.
2322
2323         * runtime/JSGlobalObjectFunctions.cpp:
2324         (JSC::globalFuncProtoGetter):
2325         (JSC::globalFuncProtoSetter):
2326
2327 2015-04-23  Benjamin Poulain  <bpoulain@apple.com>
2328
2329         Remove a useless branch on DFGGraph::addShouldSpeculateMachineInt()
2330         https://bugs.webkit.org/show_bug.cgi?id=144118
2331
2332         Reviewed by Geoffrey Garen.
2333
2334         * dfg/DFGGraph.h:
2335         (JSC::DFG::Graph::addShouldSpeculateMachineInt):
2336         Both block do the same thing.
2337
2338 2015-04-23  Joseph Pecoraro  <pecoraro@apple.com>
2339
2340         Web Inspector: Speculative fix for non-main thread auto-attach failures
2341         https://bugs.webkit.org/show_bug.cgi?id=144134
2342
2343         Reviewed by Timothy Hatcher.
2344
2345         * inspector/remote/RemoteInspector.mm:
2346         (Inspector::RemoteInspector::singleton):
2347
2348 2015-04-23  Basile Clement  <basile_clement@apple.com>
2349
2350         Allow function allocation sinking
2351         https://bugs.webkit.org/show_bug.cgi?id=144016
2352
2353         Reviewed by Filip Pizlo.
2354
2355         This adds the ability to sink function allocations in the
2356         DFGObjectAllocationSinkingPhase.
2357
2358         In order to enable this, we add a new PhantomNewFunction node that is
2359         used similarily to the PhantomNewObject node, i.e. as a placeholder to replace
2360         a sunk NewFunction and keep track of the allocations that have to be performed
2361         in case of OSR exit after the sunk allocation but before the real one.
2362         The FunctionExecutable and JSLexicalEnvironment (activation) of the function
2363         are stored onto the PhantomNewFunction through PutHints in order for them
2364         to be recovered on OSR exit.
2365
2366         Contrary to sunk object allocations, sunk function allocations do not
2367         support any kind of operations (e.g. storing into a field) ; any such operation
2368         will mark the function allocation as escaping and trigger materialization. As
2369         such, function allocations can only be sunk to places where it would have been
2370         correct to syntactically move them, and we don't need a special
2371         MaterializeNewFunction node to recover possible operations on the function. A
2372         sunk NewFunction node will simply create new NewFunction nodes, then replace
2373         itself with a PhantomNewFunction node.
2374
2375         In itself, this change is not expected to have a significant impact on
2376         performances other than in degenerate cases (see e.g.
2377         JSRegress/sink-function), but it is a step towards being able to sink recursive
2378         closures onces we support CreateActivation sinking as well as allocation cycles
2379         sinking.
2380
2381         * dfg/DFGAbstractInterpreterInlines.h:
2382         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2383         * dfg/DFGClobberize.h:
2384         (JSC::DFG::clobberize):
2385         * dfg/DFGDoesGC.cpp:
2386         (JSC::DFG::doesGC):
2387         * dfg/DFGFixupPhase.cpp:
2388         (JSC::DFG::FixupPhase::fixupNode):
2389         * dfg/DFGNode.h:
2390         (JSC::DFG::Node::convertToPhantomNewFunction):
2391         (JSC::DFG::Node::isPhantomAllocation):
2392         * dfg/DFGNodeType.h:
2393         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2394         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
2395         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
2396         (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
2397         (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
2398         * dfg/DFGPredictionPropagationPhase.cpp:
2399         (JSC::DFG::PredictionPropagationPhase::propagate):
2400         * dfg/DFGPromotedHeapLocation.cpp:
2401         (WTF::printInternal):
2402         * dfg/DFGPromotedHeapLocation.h:
2403         * dfg/DFGSafeToExecute.h:
2404         (JSC::DFG::safeToExecute):
2405         * dfg/DFGSpeculativeJIT32_64.cpp:
2406         (JSC::DFG::SpeculativeJIT::compile):
2407         * dfg/DFGSpeculativeJIT64.cpp:
2408         (JSC::DFG::SpeculativeJIT::compile):
2409         * dfg/DFGValidate.cpp:
2410         (JSC::DFG::Validate::validateCPS):
2411         * ftl/FTLCapabilities.cpp:
2412         (JSC::FTL::canCompile):
2413         * ftl/FTLLowerDFGToLLVM.cpp:
2414         (JSC::FTL::LowerDFGToLLVM::compileNode):
2415         * ftl/FTLOperations.cpp:
2416         (JSC::FTL::operationMaterializeObjectInOSR):
2417         * tests/stress/function-sinking-no-double-allocate.js: Added.
2418         (call):
2419         (.f):
2420         (sink):
2421         * tests/stress/function-sinking-osrexit.js: Added.
2422         (.g):
2423         (sink):
2424         * tests/stress/function-sinking-put.js: Added.
2425         (.g):
2426         (sink):
2427
2428 2015-04-23  Basile Clement  <basile_clement@apple.com>
2429
2430         Make FunctionRareData allocation thread-safe
2431         https://bugs.webkit.org/show_bug.cgi?id=144001
2432
2433         Reviewed by Mark Lam.
2434
2435         The two things we want to prevent are:
2436
2437          1. A thread seeing a pointer to a not-yet-fully-created rare data from
2438             a JSFunction
2439          2. A thread seeing a pointer to a not-yet-fully-created Structure from
2440             an ObjectAllocationProfile
2441
2442         For 1., only the JS thread can be creating the rare data (in
2443         runtime/CommonSlowPaths.cpp or in dfg/DFGOperations.cpp), so we don't need to
2444         worry about concurrent writes, and we don't need any fences when *reading* the
2445         rare data from the JS thread. Thus we only need a storeStoreFence between the
2446         rare data creation and assignment to m_rareData in
2447         JSFunction::createAndInitializeRareData() to ensure that when the store to
2448         m_rareData is issued, the rare data has been properly created.
2449
2450         For the DFG compilation threads, the only place they can access the
2451         rare data is through JSFunction::rareData(), and so we only need a
2452         loadLoadFence there to ensure that when we see a non-null pointer in
2453         m_rareData, the pointed object will be seen as a fully created
2454         FunctionRareData.
2455
2456
2457         For 2., the structure is created in
2458         ObjectAllocationProfile::initialize() (which appears to be called only by the
2459         JS thread as well, in bytecode/CodeBlock.cpp and on rare data initialization,
2460         which always happen in the JS thread), and read through
2461         ObjectAllocationProfile::structure() and
2462         ObjectAllocationProfile::inlineCapacity(), so following the same reasoning we
2463         put a storeStoreFence in ObjectAllocationProfile::initialize() and a
2464         loadLoadFence in ObjectAllocationProfile::structure() (and change
2465         ObjectAllocationProfile::inlineCapacity() to go through
2466         ObjectAllocationProfile::structure()).
2467
2468         We don't need a fence in ObjectAllocationProfile::clear() because
2469         clearing the structure is already as atomic as it gets.
2470
2471         Finally, notice that we don't care about the ObjectAllocationProfile's
2472         m_allocator as that is only used by ObjectAllocationProfile::initialize() and
2473         ObjectAllocationProfile::clear() that are always run in the JS thread.
2474         ObjectAllocationProfile::isNull() could cause some trouble, but it is
2475         currently only used in the ObjectAllocationProfile::clear()'s ASSERT in the JS
2476         thread.  Doing isNull()-style pre-checks would be wrong in any other concurrent
2477         thread anyway.
2478
2479         * bytecode/ObjectAllocationProfile.h:
2480         (JSC::ObjectAllocationProfile::initialize):
2481         (JSC::ObjectAllocationProfile::structure):
2482         (JSC::ObjectAllocationProfile::inlineCapacity):
2483         * runtime/JSFunction.cpp:
2484         (JSC::JSFunction::allocateAndInitializeRareData):
2485         * runtime/JSFunction.h:
2486         (JSC::JSFunction::rareData):
2487         (JSC::JSFunction::allocationStructure): Deleted.
2488         This is no longer used, as all the accesses to the ObjectAllocationProfile go through the rare data.
2489
2490 2015-04-22  Filip Pizlo  <fpizlo@apple.com>
2491
2492         DFG should insert Phantoms late using BytecodeKills and block-local OSR availability
2493         https://bugs.webkit.org/show_bug.cgi?id=143735
2494
2495         Reviewed by Geoffrey Garen.
2496         
2497         We've always had bugs arising from the fact that we would MovHint something into a local,
2498         and then fail to keep it alive. We would then try to keep things alive by putting Phantoms
2499         on those Nodes that were MovHinted. But this became increasingly tricky. Given the
2500         sophistication of the transformations we are doing today, this approach is just not sound
2501         anymore.
2502         
2503         This comprehensively fixes these bugs by having the DFG backend automatically insert
2504         Phantoms just before codegen based on bytecode liveness. To make this practical, this also
2505         makes it much faster to query bytecode liveness.
2506         
2507         It's about as perf-neutral as it gets for a change that increases compiler work without
2508         actually optimizing anything. Later changes will remove the old Phantom-preserving logic,
2509         which should then speed us up. I can't really report concrete slow-down numbers because
2510         they are low enough to basically be in the noise. For example, a 20-iteration run of
2511         SunSpider yields "maybe 0.8% slower", whatever that means.
2512
2513         * CMakeLists.txt:
2514         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2515         * JavaScriptCore.xcodeproj/project.pbxproj:
2516         * bytecode/BytecodeLivenessAnalysis.cpp:
2517         (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
2518         * bytecode/FullBytecodeLiveness.h:
2519         (JSC::FullBytecodeLiveness::getLiveness):
2520         * bytecode/VirtualRegister.h:
2521         (JSC::VirtualRegister::operator+):
2522         (JSC::VirtualRegister::operator-):
2523         * dfg/DFGForAllKills.h:
2524         (JSC::DFG::forAllLiveNodesAtTail):
2525         (JSC::DFG::forAllKilledOperands):
2526         (JSC::DFG::forAllKilledNodesAtNodeIndex):
2527         * dfg/DFGGraph.cpp:
2528         (JSC::DFG::Graph::isLiveInBytecode):
2529         (JSC::DFG::Graph::localsLiveInBytecode):
2530         * dfg/DFGGraph.h:
2531         (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
2532         (JSC::DFG::Graph::forAllLiveInBytecode):
2533         * dfg/DFGMayExit.cpp:
2534         (JSC::DFG::mayExit):
2535         * dfg/DFGMovHintRemovalPhase.cpp:
2536         * dfg/DFGNodeType.h:
2537         * dfg/DFGPhantomInsertionPhase.cpp: Added.
2538         (JSC::DFG::performPhantomInsertion):
2539         * dfg/DFGPhantomInsertionPhase.h: Added.
2540         * dfg/DFGPlan.cpp:
2541         (JSC::DFG::Plan::compileInThreadImpl):
2542         * dfg/DFGScoreBoard.h:
2543         (JSC::DFG::ScoreBoard::sortFree):
2544         (JSC::DFG::ScoreBoard::assertClear):
2545         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
2546         (JSC::DFG::VirtualRegisterAllocationPhase::run):
2547         * ftl/FTLLowerDFGToLLVM.cpp:
2548         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
2549         * tests/stress/phantom-inadequacy.js: Added.
2550         (bar):
2551         (baz):
2552         (foo):
2553
2554 2015-04-23  Filip Pizlo  <fpizlo@apple.com>
2555
2556         Rename HardPhantom to MustGenerate.
2557
2558         Rubber stamped by Geoffrey Garen.
2559         
2560         We are steadily moving towards Phantom just being a backend hack in the DFG. HardPhantom
2561         is more than that; it's a utility for forcing the execution of otherwise killable nodes.
2562         NodeMustGenerate is the flag we use to indicate that something isn't killable. So this
2563         node should just be called MustGenerate.
2564
2565         * dfg/DFGAbstractInterpreterInlines.h:
2566         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2567         * dfg/DFGArgumentsEliminationPhase.cpp:
2568         * dfg/DFGClobberize.h:
2569         (JSC::DFG::clobberize):
2570         * dfg/DFGDCEPhase.cpp:
2571         (JSC::DFG::DCEPhase::run):
2572         * dfg/DFGDoesGC.cpp:
2573         (JSC::DFG::doesGC):
2574         * dfg/DFGFixupPhase.cpp:
2575         (JSC::DFG::FixupPhase::fixupNode):
2576         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
2577         * dfg/DFGIntegerCheckCombiningPhase.cpp:
2578         (JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd):
2579         * dfg/DFGMayExit.cpp:
2580         (JSC::DFG::mayExit):
2581         * dfg/DFGNode.h:
2582         (JSC::DFG::Node::willHaveCodeGenOrOSR):
2583         * dfg/DFGNodeType.h:
2584         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2585         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
2586         * dfg/DFGPhantomCanonicalizationPhase.cpp:
2587         (JSC::DFG::PhantomCanonicalizationPhase::run):
2588         * dfg/DFGPhantomRemovalPhase.cpp:
2589         (JSC::DFG::PhantomRemovalPhase::run):
2590         * dfg/DFGPredictionPropagationPhase.cpp:
2591         (JSC::DFG::PredictionPropagationPhase::propagate):
2592         * dfg/DFGSafeToExecute.h:
2593         (JSC::DFG::safeToExecute):
2594         * dfg/DFGSpeculativeJIT32_64.cpp:
2595         (JSC::DFG::SpeculativeJIT::compile):
2596         * dfg/DFGSpeculativeJIT64.cpp:
2597         (JSC::DFG::SpeculativeJIT::compile):
2598         * dfg/DFGTypeCheckHoistingPhase.cpp:
2599         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
2600         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
2601         * dfg/DFGVarargsForwardingPhase.cpp:
2602         * ftl/FTLCapabilities.cpp:
2603         (JSC::FTL::canCompile):
2604         * ftl/FTLLowerDFGToLLVM.cpp:
2605         (JSC::FTL::LowerDFGToLLVM::compileNode):
2606
2607 2015-04-23  Jordan Harband  <ljharb@gmail.com>
2608
2609         Implement `Object.assign`
2610         https://bugs.webkit.org/show_bug.cgi?id=143980
2611
2612         Reviewed by Filip Pizlo.
2613
2614         per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.assign
2615
2616         * builtins/ObjectConstructor.js: Added.
2617         (assign):
2618         * runtime/CommonIdentifiers.h:
2619         * runtime/JSGlobalObject.cpp:
2620         (JSC::JSGlobalObject::init):
2621         * runtime/ObjectConstructor.cpp:
2622         * runtime/ObjectConstructor.h:
2623
2624 2015-04-22  Filip Pizlo  <fpizlo@apple.com>
2625
2626         Unreviewed, fix debug build.
2627
2628         * dfg/DFGGraph.h:
2629         (JSC::DFG::Graph::performSubstitutionForEdge):
2630
2631 2015-04-22  Filip Pizlo  <fpizlo@apple.com>
2632
2633         Nodes should have an optional epoch field
2634         https://bugs.webkit.org/show_bug.cgi?id=144084
2635
2636         Reviewed by Ryosuke Niwa and Mark Lam.
2637         
2638         This makes it easier to do epoch-based analyses on nodes. I plan to do just that in
2639         https://bugs.webkit.org/show_bug.cgi?id=143735. Currently the epoch field is not yet
2640         used.
2641
2642         * dfg/DFGCPSRethreadingPhase.cpp:
2643         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
2644         * dfg/DFGCSEPhase.cpp:
2645         * dfg/DFGEpoch.h:
2646         (JSC::DFG::Epoch::fromUnsigned):
2647         (JSC::DFG::Epoch::toUnsigned):
2648         * dfg/DFGGraph.cpp:
2649         (JSC::DFG::Graph::clearReplacements):
2650         (JSC::DFG::Graph::clearEpochs):
2651         * dfg/DFGGraph.h:
2652         (JSC::DFG::Graph::performSubstitutionForEdge):
2653         * dfg/DFGNode.h:
2654         (JSC::DFG::Node::Node):
2655         (JSC::DFG::Node::replaceWith):
2656         (JSC::DFG::Node::replacement):
2657         (JSC::DFG::Node::setReplacement):
2658         (JSC::DFG::Node::epoch):
2659         (JSC::DFG::Node::setEpoch):
2660         * dfg/DFGSSAConversionPhase.cpp:
2661         (JSC::DFG::SSAConversionPhase::run):
2662
2663 2015-04-22  Mark Lam  <mark.lam@apple.com>
2664
2665         Fix assertion failure and race condition in Options::dumpSourceAtDFGTime().
2666         https://bugs.webkit.org/show_bug.cgi?id=143898
2667
2668         Reviewed by Filip Pizlo.
2669
2670         CodeBlock::dumpSource() will access SourceCode strings in a way that requires
2671         ref'ing of the underlying StringImpls. This is unsafe to do from arbitrary
2672         compilation threads because StringImpls are not thread safe. As a result, we get
2673         an assertion failure when we run with JSC_dumpSourceAtDFGTime=true on a debug
2674         build.
2675
2676         This patch fixes the issue by only collecting the CodeBlock (and associated info)
2677         into a DeferredSourceDump record while compiling, and stashing it away in a
2678         deferredSourceDump list in the DeferredCompilationCallback object to be dumped
2679         later.
2680
2681         When compilation is done, the callback object will be notified that
2682         compilationDidComplete().  We will dump the SourceCode strings from there. 
2683         Since compilationDidComplete() is guaranteed to only be called on the thread
2684         doing JS execution, it is safe to access the SourceCode strings there and ref
2685         their underlying StringImpls as needed.        
2686
2687         * CMakeLists.txt:
2688         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2689         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2690         * JavaScriptCore.xcodeproj/project.pbxproj:
2691         * bytecode/DeferredCompilationCallback.cpp:
2692         (JSC::DeferredCompilationCallback::compilationDidComplete):
2693         (JSC::DeferredCompilationCallback::sourceDumpInfo):
2694         (JSC::DeferredCompilationCallback::dumpCompiledSources):
2695         * bytecode/DeferredCompilationCallback.h:
2696         * bytecode/DeferredSourceDump.cpp: Added.
2697         (JSC::DeferredSourceDump::DeferredSourceDump):
2698         (JSC::DeferredSourceDump::dump):
2699         * bytecode/DeferredSourceDump.h: Added.
2700         * dfg/DFGByteCodeParser.cpp:
2701         (JSC::DFG::ByteCodeParser::parseCodeBlock):
2702         * dfg/DFGDriver.cpp:
2703         (JSC::DFG::compileImpl):
2704
2705 2015-04-22  Benjamin Poulain  <benjamin@webkit.org>
2706
2707         Implement String.codePointAt()
2708         https://bugs.webkit.org/show_bug.cgi?id=143934
2709
2710         Reviewed by Darin Adler.
2711
2712         This patch adds String.codePointAt() as defined by ES6.
2713         I opted for a C++ implementation for now.
2714
2715         * runtime/StringPrototype.cpp:
2716         (JSC::StringPrototype::finishCreation):
2717         (JSC::codePointAt):
2718         (JSC::stringProtoFuncCodePointAt):
2719
2720 2015-04-22  Mark Lam  <mark.lam@apple.com>
2721
2722         SparseArrayEntry's write barrier owner should be the SparseArrayValueMap.
2723         https://bugs.webkit.org/show_bug.cgi?id=144067
2724
2725         Reviewed by Michael Saboff.
2726
2727         Currently, there are a few places where the JSObject that owns the
2728         SparseArrayValueMap is designated as the owner of the SparseArrayEntry
2729         write barrier.  This is a bug and can result in the GC collecting the
2730         SparseArrayEntry even though it is being referenced by the
2731         SparseArrayValueMap.  This patch fixes the bug.
2732
2733         * runtime/JSObject.cpp:
2734         (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists):
2735         (JSC::JSObject::putIndexedDescriptor):
2736         * tests/stress/sparse-array-entry-update-144067.js: Added.
2737         (useMemoryToTriggerGCs):
2738         (foo):
2739
2740 2015-04-22  Mark Lam  <mark.lam@apple.com>
2741
2742         Give the heap object iterators the ability to return early.
2743         https://bugs.webkit.org/show_bug.cgi?id=144011
2744
2745         Reviewed by Michael Saboff.
2746
2747         JSDollarVMPrototype::isValidCell() uses a heap object iterator to validate
2748         candidate cell pointers, and, when in use, is called a lot more often than
2749         the normal way those iterators are used.  As a result, I see my instrumented
2750         VM killed with a SIGXCPU (CPU time limit exceeded).  This patch gives the
2751         callback functor the ability to tell the iterators to return early when the
2752         functor no longer needs to continue iterating.  With this, my instrumented
2753         VM is useful again for debugging.
2754
2755         Since heap iteration is not something that we do in a typical fast path,
2756         I don't expect this to have any noticeable impact on performance.
2757
2758         I also renamed ObjectAddressCheckFunctor to CellAddressCheckFunctor since
2759         it checks JSCell addresses, not just JSObjects.
2760
2761         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2762         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2763         * JavaScriptCore.xcodeproj/project.pbxproj:
2764         * debugger/Debugger.cpp:
2765         * heap/GCLogging.cpp:
2766         (JSC::LoggingFunctor::operator()):
2767         * heap/Heap.cpp:
2768         (JSC::Zombify::visit):
2769         (JSC::Zombify::operator()):
2770         * heap/HeapStatistics.cpp:
2771         (JSC::StorageStatistics::visit):
2772         (JSC::StorageStatistics::operator()):
2773         * heap/HeapVerifier.cpp:
2774         (JSC::GatherLiveObjFunctor::visit):
2775         (JSC::GatherLiveObjFunctor::operator()):
2776         * heap/MarkedBlock.cpp:
2777         (JSC::SetNewlyAllocatedFunctor::operator()):
2778         * heap/MarkedBlock.h:
2779         (JSC::MarkedBlock::forEachCell):
2780         (JSC::MarkedBlock::forEachLiveCell):
2781         (JSC::MarkedBlock::forEachDeadCell):
2782         * heap/MarkedSpace.h:
2783         (JSC::MarkedSpace::forEachLiveCell):
2784         (JSC::MarkedSpace::forEachDeadCell):
2785         * inspector/agents/InspectorRuntimeAgent.cpp:
2786         (Inspector::TypeRecompiler::visit):
2787         (Inspector::TypeRecompiler::operator()):
2788         * runtime/IterationStatus.h: Added.
2789         * runtime/JSGlobalObject.cpp:
2790         * runtime/VM.cpp:
2791         (JSC::StackPreservingRecompiler::visit):
2792         (JSC::StackPreservingRecompiler::operator()):
2793         * tools/JSDollarVMPrototype.cpp:
2794         (JSC::CellAddressCheckFunctor::CellAddressCheckFunctor):
2795         (JSC::CellAddressCheckFunctor::operator()):
2796         (JSC::JSDollarVMPrototype::isValidCell):
2797         (JSC::ObjectAddressCheckFunctor::ObjectAddressCheckFunctor): Deleted.
2798         (JSC::ObjectAddressCheckFunctor::operator()): Deleted.
2799
2800 2015-04-22  Yusuke Suzuki  <utatane.tea@gmail.com>
2801
2802         [[Set]] should be properly executed in JS builtins
2803         https://bugs.webkit.org/show_bug.cgi?id=143996
2804
2805         Reviewed by Geoffrey Garen.
2806
2807         Currently, all assignments in builtins JS code is compiled into put_by_val_direct.
2808         However,
2809
2810         1. Some functions (like Array.from) needs [[Set]]. (but it is now compiled into put_by_val_direct, [[DefineOwnProperty]]).
2811         2. It's different from the default JS behavior.
2812
2813         In this patch, we implement the bytecode intrinsic emitting put_by_val_direct and use it explicitly.
2814         And dropping the current hack for builtins.
2815
2816         * builtins/Array.prototype.js:
2817         (filter):
2818         (map):
2819         (find):
2820         * bytecompiler/BytecodeGenerator.cpp:
2821         (JSC::BytecodeGenerator::emitPutByVal):
2822         * tests/stress/array-fill-put-by-val.js: Added.
2823         (shouldThrow):
2824         (.set get array):
2825         * tests/stress/array-filter-put-by-val-direct.js: Added.
2826         (shouldBe):
2827         (.set get var):
2828         * tests/stress/array-find-does-not-lookup-twice.js: Added.
2829         (shouldBe):
2830         (shouldThrow):
2831         (.get shouldBe):
2832         * tests/stress/array-from-put-by-val-direct.js: Added.
2833         (shouldBe):
2834         (.set get var):
2835         * tests/stress/array-from-set-length.js: Added.
2836         (shouldBe):
2837         (ArrayLike):
2838         (ArrayLike.prototype.set length):
2839         (ArrayLike.prototype.get length):
2840         * tests/stress/array-map-put-by-val-direct.js: Added.
2841         (shouldBe):
2842         (.set get var):
2843
2844 2015-04-22  Basile Clement  <basile_clement@apple.com>
2845  
2846         Don't de-allocate FunctionRareData
2847         https://bugs.webkit.org/show_bug.cgi?id=144000
2848
2849         Reviewed by Michael Saboff.
2850
2851         A function rare data (containing most notably its allocation profile) is currently
2852         freed and re-allocated each time the function's prototype is cleared.
2853         This is not optimal as it means we are invalidating the watchpoint and recompiling the
2854         scope each time the prototype is cleared.
2855
2856         This makes it so that a single rare data is reused, clearing the underlying
2857         ObjectAllocationProfile instead of throwing away the whole rare data on
2858         .prototype updates.
2859
2860         * runtime/FunctionRareData.cpp:
2861         (JSC::FunctionRareData::create):
2862         (JSC::FunctionRareData::finishCreation):
2863         * runtime/FunctionRareData.h:
2864         * runtime/JSFunction.cpp:
2865         (JSC::JSFunction::allocateAndInitializeRareData):
2866         (JSC::JSFunction::initializeRareData):
2867
2868 2015-04-21  Filip Pizlo  <fpizlo@apple.com>
2869
2870         Unreviewed, fix 32-bit. Forgot to make this simple change to 32_64 as well.
2871
2872         * dfg/DFGSpeculativeJIT32_64.cpp:
2873         (JSC::DFG::SpeculativeJIT::compile):
2874
2875 2015-04-21  Filip Pizlo  <fpizlo@apple.com>
2876
2877         DFG should allow Phantoms after terminals
2878         https://bugs.webkit.org/show_bug.cgi?id=126778
2879
2880         Reviewed by Mark Lam.
2881         
2882         It's important for us to be able to place liveness-marking nodes after nodes that do
2883         things. These liveness-marking nodes are nops. Previously, we disallowed such nodes after
2884         terminals. That made things awkward, especially for Switch and Branch, which may do
2885         things that necessitate liveness markers (for example they might want to use a converted
2886         version of a value rather than the value that was MovHinted). We previously made this
2887         work by disallowing certain optimizations on Switch and Branch, which was probably a bad
2888         thing.
2889         
2890         This changes our IR to allow for the terminal to not be the last node in a block. Asking
2891         for the terminal involves a search. DFG::validate() checks that the nodes after the
2892         terminal are liveness markers that have no effects or checks.
2893         
2894         This is perf-neutral but will allow more optimizations in the future. It will also make
2895         it cleaner to fix https://bugs.webkit.org/show_bug.cgi?id=143735.
2896
2897         * dfg/DFGBasicBlock.cpp:
2898         (JSC::DFG::BasicBlock::replaceTerminal):
2899         * dfg/DFGBasicBlock.h:
2900         (JSC::DFG::BasicBlock::findTerminal):
2901         (JSC::DFG::BasicBlock::terminal):
2902         (JSC::DFG::BasicBlock::insertBeforeTerminal):
2903         (JSC::DFG::BasicBlock::numSuccessors):
2904         (JSC::DFG::BasicBlock::successor):
2905         (JSC::DFG::BasicBlock::successorForCondition):
2906         (JSC::DFG::BasicBlock::successors):
2907         (JSC::DFG::BasicBlock::last): Deleted.
2908         (JSC::DFG::BasicBlock::takeLast): Deleted.
2909         (JSC::DFG::BasicBlock::insertBeforeLast): Deleted.
2910         (JSC::DFG::BasicBlock::SuccessorsIterable::SuccessorsIterable): Deleted.
2911         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::iterator): Deleted.
2912         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator*): Deleted.
2913         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator++): Deleted.
2914         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator==): Deleted.
2915         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator!=): Deleted.
2916         (JSC::DFG::BasicBlock::SuccessorsIterable::begin): Deleted.
2917         (JSC::DFG::BasicBlock::SuccessorsIterable::end): Deleted.
2918         * dfg/DFGBasicBlockInlines.h:
2919         (JSC::DFG::BasicBlock::appendNonTerminal):
2920         (JSC::DFG::BasicBlock::replaceTerminal):
2921         * dfg/DFGByteCodeParser.cpp:
2922         (JSC::DFG::ByteCodeParser::addToGraph):
2923         (JSC::DFG::ByteCodeParser::inlineCall):
2924         (JSC::DFG::ByteCodeParser::handleInlining):
2925         (JSC::DFG::ByteCodeParser::parseBlock):
2926         (JSC::DFG::ByteCodeParser::linkBlock):
2927         (JSC::DFG::ByteCodeParser::parseCodeBlock):
2928         * dfg/DFGCFGSimplificationPhase.cpp:
2929         (JSC::DFG::CFGSimplificationPhase::run):
2930         (JSC::DFG::CFGSimplificationPhase::convertToJump):
2931         (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
2932         * dfg/DFGCPSRethreadingPhase.cpp:
2933         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
2934         * dfg/DFGCommon.h:
2935         (JSC::DFG::NodeAndIndex::NodeAndIndex):
2936         (JSC::DFG::NodeAndIndex::operator!):
2937         * dfg/DFGFixupPhase.cpp:
2938         (JSC::DFG::FixupPhase::fixupBlock):
2939         (JSC::DFG::FixupPhase::fixupNode):
2940         (JSC::DFG::FixupPhase::injectTypeConversionsInBlock):
2941         (JSC::DFG::FixupPhase::clearPhantomsAtEnd): Deleted.
2942         * dfg/DFGForAllKills.h:
2943         (JSC::DFG::forAllLiveNodesAtTail):
2944         * dfg/DFGGraph.cpp:
2945         (JSC::DFG::Graph::terminalsAreValid):
2946         (JSC::DFG::Graph::dumpBlockHeader):
2947         * dfg/DFGGraph.h:
2948         * dfg/DFGInPlaceAbstractState.cpp:
2949         (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
2950         * dfg/DFGLICMPhase.cpp:
2951         (JSC::DFG::LICMPhase::run):
2952         (JSC::DFG::LICMPhase::attemptHoist):
2953         * dfg/DFGMovHintRemovalPhase.cpp:
2954         * dfg/DFGNode.h:
2955         (JSC::DFG::Node::SuccessorsIterable::SuccessorsIterable):
2956         (JSC::DFG::Node::SuccessorsIterable::iterator::iterator):
2957         (JSC::DFG::Node::SuccessorsIterable::iterator::operator*):
2958         (JSC::DFG::Node::SuccessorsIterable::iterator::operator++):
2959         (JSC::DFG::Node::SuccessorsIterable::iterator::operator==):
2960         (JSC::DFG::Node::SuccessorsIterable::iterator::operator!=):
2961         (JSC::DFG::Node::SuccessorsIterable::begin):
2962         (JSC::DFG::Node::SuccessorsIterable::end):
2963         (JSC::DFG::Node::successors):
2964         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2965         (JSC::DFG::ObjectAllocationSinkingPhase::determineMaterializationPoints):
2966         (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
2967         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
2968         * dfg/DFGPhantomRemovalPhase.cpp:
2969         (JSC::DFG::PhantomRemovalPhase::run):
2970         * dfg/DFGPutStackSinkingPhase.cpp:
2971         * dfg/DFGSSAConversionPhase.cpp:
2972         (JSC::DFG::SSAConversionPhase::run):
2973         * dfg/DFGSpeculativeJIT.h:
2974         (JSC::DFG::SpeculativeJIT::detectPeepHoleBranch):
2975         * dfg/DFGSpeculativeJIT32_64.cpp:
2976         (JSC::DFG::SpeculativeJIT::compile):
2977         * dfg/DFGSpeculativeJIT64.cpp:
2978         (JSC::DFG::SpeculativeJIT::compile):
2979         * dfg/DFGStaticExecutionCountEstimationPhase.cpp:
2980         (JSC::DFG::StaticExecutionCountEstimationPhase::run):
2981         * dfg/DFGTierUpCheckInjectionPhase.cpp:
2982         (JSC::DFG::TierUpCheckInjectionPhase::run):
2983         * dfg/DFGValidate.cpp:
2984         (JSC::DFG::Validate::validate):
2985         * ftl/FTLLowerDFGToLLVM.cpp:
2986         (JSC::FTL::LowerDFGToLLVM::compileNode):
2987         * tests/stress/closure-call-exit.js: Added.
2988         (foo):
2989
2990 2015-04-21  Basile Clement  <basile_clement@apple.com>
2991
2992         PhantomNewObject should be marked NodeMustGenerate
2993         https://bugs.webkit.org/show_bug.cgi?id=143974
2994
2995         Reviewed by Filip Pizlo.
2996
2997         * dfg/DFGNode.h:
2998         (JSC::DFG::Node::convertToPhantomNewObject):
2999         Was not properly marking NodeMustGenerate when converting.
3000
3001 2015-04-21  Filip Pizlo  <fpizlo@apple.com>
3002
3003         DFG Call/ConstructForwardVarargs fails to restore the stack pointer
3004         https://bugs.webkit.org/show_bug.cgi?id=144007
3005
3006         Reviewed by Mark Lam.
3007         
3008         We were conditioning the stack pointer restoration on isVarargs, but we also need to do it
3009         if isForwardVarargs.
3010
3011         * dfg/DFGSpeculativeJIT32_64.cpp:
3012         (JSC::DFG::SpeculativeJIT::emitCall):
3013         * dfg/DFGSpeculativeJIT64.cpp:
3014         (JSC::DFG::SpeculativeJIT::emitCall):
3015         * tests/stress/varargs-then-slow-call.js: Added.
3016         (foo):
3017         (bar):
3018         (fuzz):
3019         (baz):
3020
3021 2015-04-21  Basile Clement  <basile_clement@apple.com>
3022
3023         Remove AllocationProfileWatchpoint node
3024         https://bugs.webkit.org/show_bug.cgi?id=143999
3025
3026         Reviewed by Filip Pizlo.
3027
3028         * dfg/DFGAbstractInterpreterInlines.h:
3029         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3030         * dfg/DFGByteCodeParser.cpp:
3031         (JSC::DFG::ByteCodeParser::parseBlock):
3032         * dfg/DFGClobberize.h:
3033         (JSC::DFG::clobberize):
3034         * dfg/DFGDoesGC.cpp:
3035         (JSC::DFG::doesGC):
3036         * dfg/DFGFixupPhase.cpp:
3037         (JSC::DFG::FixupPhase::fixupNode):
3038         * dfg/DFGHeapLocation.cpp:
3039         (WTF::printInternal):
3040         * dfg/DFGHeapLocation.h:
3041         * dfg/DFGNode.h:
3042         (JSC::DFG::Node::hasCellOperand):
3043         * dfg/DFGNodeType.h:
3044         * dfg/DFGPredictionPropagationPhase.cpp:
3045         (JSC::DFG::PredictionPropagationPhase::propagate):
3046         * dfg/DFGSafeToExecute.h:
3047         (JSC::DFG::safeToExecute):
3048         * dfg/DFGSpeculativeJIT32_64.cpp:
3049         (JSC::DFG::SpeculativeJIT::compile):
3050         * dfg/DFGSpeculativeJIT64.cpp:
3051         (JSC::DFG::SpeculativeJIT::compile):
3052         * dfg/DFGWatchpointCollectionPhase.cpp:
3053         (JSC::DFG::WatchpointCollectionPhase::handle):
3054         * ftl/FTLCapabilities.cpp:
3055         (JSC::FTL::canCompile):
3056         * ftl/FTLLowerDFGToLLVM.cpp:
3057         (JSC::FTL::LowerDFGToLLVM::compileNode):
3058         * runtime/JSFunction.h:
3059         (JSC::JSFunction::rareData):
3060         (JSC::JSFunction::allocationProfileWatchpointSet): Deleted.
3061
3062 2015-04-19  Filip Pizlo  <fpizlo@apple.com>
3063
3064         MovHint should be a strong use
3065         https://bugs.webkit.org/show_bug.cgi?id=143734
3066
3067         Reviewed by Geoffrey Garen.
3068         
3069         This disables any DCE that assumes equivalence between DFG IR uses and bytecode uses. Doing
3070         so is a major step towards allowing more fancy DFG transformations and also probably fixing
3071         some bugs.
3072         
3073         Just making MovHint a strong use would also completely disable DCE. So we mitigate this by
3074         introducing a MovHint removal phase that runs in FTL.
3075         
3076         This is a slight slowdown on Octane/gbemu, but it's basically neutral on suite averages.
3077
3078         * CMakeLists.txt:
3079         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3080         * JavaScriptCore.xcodeproj/project.pbxproj:
3081         * bytecode/CodeOrigin.cpp:
3082         (JSC::InlineCallFrame::dumpInContext):
3083         * dfg/DFGDCEPhase.cpp:
3084         (JSC::DFG::DCEPhase::fixupBlock):
3085         * dfg/DFGDisassembler.cpp:
3086         (JSC::DFG::Disassembler::createDumpList):
3087         * dfg/DFGEpoch.cpp: Added.
3088         (JSC::DFG::Epoch::dump):
3089         * dfg/DFGEpoch.h: Added.
3090         (JSC::DFG::Epoch::Epoch):
3091         (JSC::DFG::Epoch::first):
3092         (JSC::DFG::Epoch::operator!):
3093         (JSC::DFG::Epoch::next):
3094         (JSC::DFG::Epoch::bump):
3095         (JSC::DFG::Epoch::operator==):
3096         (JSC::DFG::Epoch::operator!=):
3097         * dfg/DFGMayExit.cpp:
3098         (JSC::DFG::mayExit):
3099         * dfg/DFGMovHintRemovalPhase.cpp: Added.
3100         (JSC::DFG::performMovHintRemoval):
3101         * dfg/DFGMovHintRemovalPhase.h: Added.
3102         * dfg/DFGNodeType.h:
3103         * dfg/DFGPlan.cpp:
3104         (JSC::DFG::Plan::compileInThreadImpl):
3105         * dfg/DFGSpeculativeJIT.cpp:
3106         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
3107         * dfg/DFGSpeculativeJIT64.cpp:
3108         (JSC::DFG::SpeculativeJIT::compile):
3109         * runtime/Options.h:
3110
3111 2015-04-21  Basile Clement  <basile_clement@apple.com>
3112
3113         REGRESSION (r182899): icloud.com crashes
3114         https://bugs.webkit.org/show_bug.cgi?id=143960
3115
3116         Reviewed by Filip Pizlo.
3117
3118         * runtime/JSFunction.h:
3119         (JSC::JSFunction::allocationStructure):
3120         * tests/stress/dfg-rare-data.js: Added.
3121         (F): Regression test
3122
3123 2015-04-21  Michael Saboff  <msaboff@apple.com>
3124
3125         Crash in JSC::Interpreter::execute
3126         https://bugs.webkit.org/show_bug.cgi?id=142625
3127
3128         Reviewed by Filip Pizlo.
3129
3130         We need to keep the FunctionExecutables in the code block for the eval flavor of 
3131         Interpreter::execute() in order to create the scope used to eval.
3132
3133         * bytecode/CodeBlock.cpp:
3134         (JSC::CodeBlock::jettisonFunctionDeclsAndExprs): Deleted.
3135         * bytecode/CodeBlock.h:
3136         * dfg/DFGGraph.cpp:
3137         (JSC::DFG::Graph::registerFrozenValues):
3138
3139 2015-04-21  Chris Dumez  <cdumez@apple.com>
3140
3141         Make Vector(const Vector<T, otherCapacity, otherOverflowBehaviour>&) constructor explicit
3142         https://bugs.webkit.org/show_bug.cgi?id=143970
3143
3144         Reviewed by Darin Adler.
3145
3146         Make Vector(const Vector<T, otherCapacity, otherOverflowBehaviour>&)
3147         constructor explicit as it copies the vector and it is easy to call it
3148         by mistake.
3149
3150         * bytecode/UnlinkedInstructionStream.cpp:
3151         (JSC::UnlinkedInstructionStream::UnlinkedInstructionStream):
3152         * bytecode/UnlinkedInstructionStream.h:
3153         * ftl/FTLLowerDFGToLLVM.cpp:
3154         (JSC::FTL::LowerDFGToLLVM::lower):
3155
3156 2015-04-20  Basile Clement  <basile_clement@apple.com>
3157
3158         PhantomNewObject should be marked NodeMustGenerate
3159         https://bugs.webkit.org/show_bug.cgi?id=143974
3160
3161         Reviewed by Filip Pizlo.
3162
3163         * dfg/DFGNodeType.h: Mark PhantomNewObject as NodeMustGenerate
3164
3165 2015-04-20  Joseph Pecoraro  <pecoraro@apple.com>
3166
3167         Cleanup some StringBuilder use
3168         https://bugs.webkit.org/show_bug.cgi?id=143550
3169
3170         Reviewed by Darin Adler.
3171
3172         * runtime/Symbol.cpp:
3173         (JSC::Symbol::descriptiveString):
3174         * runtime/TypeProfiler.cpp:
3175         (JSC::TypeProfiler::typeInformationForExpressionAtOffset):
3176         * runtime/TypeSet.cpp:
3177         (JSC::TypeSet::toJSONString):
3178         (JSC::StructureShape::propertyHash):
3179         (JSC::StructureShape::stringRepresentation):
3180         (JSC::StructureShape::toJSONString):
3181
3182 2015-04-20  Mark Lam  <mark.lam@apple.com>
3183
3184         Add debugging tools to test if a given pointer is a valid object and in the heap.
3185         https://bugs.webkit.org/show_bug.cgi?id=143910
3186
3187         Reviewed by Geoffrey Garen.
3188
3189         When doing debugging from lldb, sometimes, it is useful to be able to tell if a
3190         purported JSObject is really a valid object in the heap or not.  We can add the
3191         following utility functions to help:
3192             isValidCell(heap, candidate) - returns true if the candidate is a "live" cell in the heap.
3193             isInHeap(heap, candidate) - returns true if the candidate is the heap's Object space or Storage space.
3194             isInObjectSpace(heap, candidate) - returns true if the candidate is the heap's Object space.
3195             isInStorageSpace(heap, candidate) - returns true if the candidate is the heap's Storage space.
3196
3197         Also moved lldb callable debug utility function prototypes from
3198         JSDollarVMPrototype.cpp to JSDollarVMPrototype.h as static members of the
3199         JSDollarVMPrototype class.  This is so that we can conveniently #include that
3200         file to get the prototypes when we need to call them programmatically from
3201         instrumentation that we add while debugging an issue.
3202
3203         * heap/Heap.h:
3204         (JSC::Heap::storageSpace):
3205         * tools/JSDollarVMPrototype.cpp:
3206         (JSC::JSDollarVMPrototype::currentThreadOwnsJSLock):
3207         (JSC::ensureCurrentThreadOwnsJSLock):
3208         (JSC::JSDollarVMPrototype::gc):
3209         (JSC::functionGC):
3210         (JSC::JSDollarVMPrototype::edenGC):
3211         (JSC::functionEdenGC):
3212         (JSC::JSDollarVMPrototype::isInHeap):
3213         (JSC::JSDollarVMPrototype::isInObjectSpace):
3214         (JSC::JSDollarVMPrototype::isInStorageSpace):
3215         (JSC::ObjectAddressCheckFunctor::ObjectAddressCheckFunctor):
3216         (JSC::ObjectAddressCheckFunctor::operator()):
3217         (JSC::JSDollarVMPrototype::isValidCell):
3218         (JSC::JSDollarVMPrototype::isValidCodeBlock):
3219         (JSC::JSDollarVMPrototype::codeBlockForFrame):
3220         (JSC::functionCodeBlockForFrame):
3221         (JSC::codeBlockFromArg):
3222         (JSC::JSDollarVMPrototype::printCallFrame):
3223         (JSC::JSDollarVMPrototype::printStack):
3224         (JSC::JSDollarVMPrototype::printValue):
3225         (JSC::currentThreadOwnsJSLock): Deleted.
3226         (JSC::gc): Deleted.
3227         (JSC::edenGC): Deleted.
3228         (JSC::isValidCodeBlock): Deleted.
3229         (JSC::codeBlockForFrame): Deleted.
3230         (JSC::printCallFrame): Deleted.
3231         (JSC::printStack): Deleted.
3232         (JSC::printValue): Deleted.
3233         * tools/JSDollarVMPrototype.h:
3234
3235 2015-04-20  Joseph Pecoraro  <pecoraro@apple.com>
3236
3237         Web Inspector: Improve Support for WeakSet in Console
3238         https://bugs.webkit.org/show_bug.cgi?id=143951
3239
3240         Reviewed by Darin Adler.
3241
3242         * inspector/InjectedScriptSource.js:
3243         * inspector/JSInjectedScriptHost.cpp:
3244         (Inspector::JSInjectedScriptHost::subtype):
3245         (Inspector::JSInjectedScriptHost::weakSetSize):
3246         (Inspector::JSInjectedScriptHost::weakSetEntries):
3247         * inspector/JSInjectedScriptHost.h:
3248         * inspector/JSInjectedScriptHostPrototype.cpp:
3249         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
3250         (Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetSize):
3251         (Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetEntries):
3252         Treat WeakSets like special sets.
3253
3254         * inspector/protocol/Runtime.json:
3255         Add a new object subtype, "weakset".
3256
3257 2015-04-20  Yusuke Suzuki  <utatane.tea@gmail.com>
3258
3259         HashMap storing PropertyKey StringImpl* need to use IdentifierRepHash to handle Symbols
3260         https://bugs.webkit.org/show_bug.cgi?id=143947
3261
3262         Reviewed by Darin Adler.
3263
3264         Type profiler has map between PropertyKey (StringImpl*) and offset.
3265         StringImpl* is also used for Symbol PropertyKey.
3266         So equality of hash tables is considered by interned StringImpl*'s pointer value.
3267         To do so, use IdentifierRepHash instead of StringHash.
3268
3269         * runtime/SymbolTable.h:
3270
3271 2015-04-20  Jordan Harband  <ljharb@gmail.com>
3272
3273         Implement `Object.is`
3274         https://bugs.webkit.org/show_bug.cgi?id=143865
3275
3276         Reviewed by Darin Adler.
3277
3278         Expose sameValue to JS, via Object.is
3279         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.is
3280
3281         * runtime/ObjectConstructor.cpp:
3282         (JSC::objectConstructorIs):
3283         * runtime/PropertyDescriptor.cpp:
3284         (JSC::sameValue):
3285
3286 2015-04-19  Darin Adler  <darin@apple.com>
3287
3288         Remove all the remaining uses of OwnPtr and PassOwnPtr in JavaScriptCore
3289         https://bugs.webkit.org/show_bug.cgi?id=143941
3290
3291         Reviewed by Gyuyoung Kim.
3292
3293         * API/JSCallbackObject.h: Use unique_ptr for m_callbackObjectData.
3294         * API/JSCallbackObjectFunctions.h: Ditto.
3295
3296         * API/ObjCCallbackFunction.h: Use unique_ptr for the arguments to the
3297         create function and the constructor and for m_impl.
3298         * API/ObjCCallbackFunction.mm:
3299         (CallbackArgumentOfClass::CallbackArgumentOfClass): Streamline this
3300         class by using RetainPtr<Class>.
3301         (ArgumentTypeDelegate::typeInteger): Use make_unique.
3302         (ArgumentTypeDelegate::typeDouble): Ditto.
3303         (ArgumentTypeDelegate::typeBool): Ditto.
3304         (ArgumentTypeDelegate::typeVoid): Ditto.
3305         (ArgumentTypeDelegate::typeId): Ditto.
3306         (ArgumentTypeDelegate::typeOfClass): Ditto.
3307         (ArgumentTypeDelegate::typeBlock): Ditto.
3308         (ArgumentTypeDelegate::typeStruct): Ditto.
3309         (ResultTypeDelegate::typeInteger): Ditto.
3310         (ResultTypeDelegate::typeDouble): Ditto.
3311         (ResultTypeDelegate::typeBool): Ditto.
3312         (ResultTypeDelegate::typeVoid): Ditto.
3313         (ResultTypeDelegate::typeId): Ditto.
3314         (ResultTypeDelegate::typeOfClass): Ditto.
3315         (ResultTypeDelegate::typeBlock): Ditto.
3316         (ResultTypeDelegate::typeStruct): Ditto.
3317         (JSC::ObjCCallbackFunctionImpl::ObjCCallbackFunctionImpl): Use
3318         unique_ptr for the arguments to the constructor, m_arguments, and m_result.
3319         Use RetainPtr<Class> for m_instanceClass.
3320         (JSC::objCCallbackFunctionCallAsConstructor): Use nullptr instead of nil or 0
3321         for non-Objective-C object pointer null.
3322         (JSC::ObjCCallbackFunction::ObjCCallbackFunction): Use unique_ptr for
3323         the arguments to the constructor and for m_impl.
3324         (JSC::ObjCCallbackFunction::create): Use unique_ptr for arguments.
3325         (skipNumber): Mark this static since it's local to this source file.
3326         (objCCallbackFunctionForInvocation): Call parseObjCType without doing any
3327         explicit adoptPtr since the types in the traits are now unique_ptr. Also use
3328         nullptr instead of nil for JSObjectRef values.
3329         (objCCallbackFunctionForMethod): Tweaked comment.
3330         (objCCallbackFunctionForBlock): Use nullptr instead of 0 for JSObjectRef.
3331
3332         * bytecode/CallLinkInfo.h: Removed unneeded include of OwnPtr.h.
3333
3334         * heap/GCThread.cpp:
3335         (JSC::GCThread::GCThread): Use unique_ptr.
3336         * heap/GCThread.h: Use unique_ptr for arguments to the constructor and for
3337         m_slotVisitor and m_copyVisitor.
3338         * heap/GCThreadSharedData.cpp:
3339         (JSC::GCThreadSharedData::GCThreadSharedData): Ditto.
3340
3341         * parser/SourceProvider.h: Removed unneeded include of PassOwnPtr.h.
3342
3343 2015-04-19  Benjamin Poulain  <benjamin@webkit.org>
3344
3345         Improve the feature.json files
3346
3347         * features.json:
3348
3349 2015-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>
3350
3351         Introduce bytecode intrinsics
3352         https://bugs.webkit.org/show_bug.cgi?id=143926
3353
3354         Reviewed by Filip Pizlo.
3355
3356         This patch introduces bytecode level intrinsics into builtins/*.js JS code.
3357         When implementing functions in builtins/*.js,
3358         sometimes we require lower level functionality.
3359
3360         For example, in the current Array.from, we use `result[k] = value`.
3361         The spec requires `[[DefineOwnProperty]]` operation here.
3362         However, usual `result[k] = value` is evaluated as `[[Set]]`. (`PutValue` => `[[Set]]`)
3363         So if we implement `Array.prototype[k]` getter/setter, the difference is observable.
3364
3365         Ideally, reaching here, we would like to use put_by_val_direct bytecode.
3366         However, there's no syntax to generate it directly.
3367
3368         This patch introduces bytecode level intrinsics into JSC BytecodeCompiler.
3369         Like @call, @apply, we introduce a new node, Intrinsic.
3370         These are generated when calling appropriate private symbols in privileged code.
3371         AST parser detects them and generates Intrinsic nodes and
3372         BytecodeCompiler detects them and generate required bytecodes.
3373
3374         Currently, Array.from implementation works fine without this patch.
3375         This is because when the target code is builtin JS,
3376         BytecodeGenerator emits put_by_val_direct instead of put_by_val.
3377         This solves the above issue. However, instead of solving this issue,
3378         it raises another issue; There's no way to emit `[[Set]]` operation.
3379         `[[Set]]` operation is actually used in the spec (Array.from's "length" is set by `[[Set]]`).
3380         So to implement it precisely, introducing bytecode level intrinsics is necessary.
3381
3382         In the subsequent fixes, we'll remove that special path emitting put_by_val_direct
3383         for `result[k] = value` under builtin JS environment. Instead of that special handling,
3384         use bytecode intrinsics instead. It solves problems and it is more intuitive
3385         because written JS code in builtin works as the same to the usual JS code.
3386
3387         * CMakeLists.txt:
3388         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3389         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3390         * JavaScriptCore.xcodeproj/project.pbxproj:
3391         * builtins/ArrayConstructor.js:
3392         (from):
3393         * bytecode/BytecodeIntrinsicRegistry.cpp: Added.
3394         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
3395         (JSC::BytecodeIntrinsicRegistry::lookup):
3396         * bytecode/BytecodeIntrinsicRegistry.h: Added.
3397         * bytecompiler/NodesCodegen.cpp:
3398         (JSC::BytecodeIntrinsicNode::emitBytecode):
3399         (JSC::BytecodeIntrinsicNode::emit_intrinsic_putByValDirect):
3400         * parser/ASTBuilder.h:
3401         (JSC::ASTBuilder::makeFunctionCallNode):
3402         * parser/NodeConstructors.h:
3403         (JSC::BytecodeIntrinsicNode::BytecodeIntrinsicNode):
3404         * parser/Nodes.h:
3405         (JSC::BytecodeIntrinsicNode::identifier):
3406         * runtime/CommonIdentifiers.cpp:
3407         (JSC::CommonIdentifiers::CommonIdentifiers):
3408         * runtime/CommonIdentifiers.h:
3409         (JSC::CommonIdentifiers::bytecodeIntrinsicRegistry):
3410         * tests/stress/array-from-with-accessors.js: Added.
3411         (shouldBe):
3412
3413 2015-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>
3414
3415         Make Builtin functions non constructible
3416         https://bugs.webkit.org/show_bug.cgi?id=143923
3417
3418         Reviewed by Darin Adler.
3419
3420         Builtin functions defined by builtins/*.js accidentally have [[Construct]].
3421         According to the spec, these functions except for explicitly defined as a constructor do not have [[Construct]].
3422         This patch fixes it. When the JS function used for a construction is builtin function, throw not a constructor error.
3423
3424         Ideally, returning ConstructTypeNone in JSFunction::getConstructData is enough.
3425         However, to avoid calling getConstructData (it involves indirect call of function pointer of getConstructData), some places do not check ConstructType.
3426         In these places, they only check the target function is JSFunction because previously JSFunction always has [[Construct]].
3427         So in this patch, we check `isBuiltinFunction()` in those places.
3428
3429         * dfg/DFGByteCodeParser.cpp:
3430         (JSC::DFG::ByteCodeParser::inliningCost):
3431         * jit/JITOperations.cpp:
3432         * llint/LLIntSlowPaths.cpp:
3433         (JSC::LLInt::setUpCall):
3434         * runtime/JSFunction.cpp:
3435         (JSC::JSFunction::getConstructData):
3436         * tests/stress/builtin-function-is-construct-type-none.js: Added.
3437         (shouldThrow):
3438
3439 2015-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>
3440
3441         [ES6] Implement WeakSet
3442         https://bugs.webkit.org/show_bug.cgi?id=142408
3443
3444         Reviewed by Darin Adler.
3445
3446         This patch implements ES6 WeakSet.
3447         Current implementation simply leverages WeakMapData with undefined value.
3448         This WeakMapData should be optimized in the same manner as MapData/SetData in the subsequent patch[1].
3449
3450         And in this patch, we also fix WeakMap/WeakSet behavior to conform the ES6 spec.
3451         Except for adders (WeakMap.prototype.set/WeakSet.prototype.add),
3452         methods return false (or undefined for WeakMap.prototype.get)
3453         when a key is not Object instead of throwing a type error.
3454
3455         [1]: https://bugs.webkit.org/show_bug.cgi?id=143919
3456
3457         * CMakeLists.txt:
3458         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3459         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3460         * JavaScriptCore.xcodeproj/project.pbxproj:
3461         * runtime/CommonIdentifiers.h:
3462         * runtime/JSGlobalObject.cpp:
3463         * runtime/JSGlobalObject.h:
3464         * runtime/JSWeakSet.cpp: Added.
3465         (JSC::JSWeakSet::finishCreation):
3466         (JSC::JSWeakSet::visitChildren):
3467         * runtime/JSWeakSet.h: Added.
3468         (JSC::JSWeakSet::createStructure):
3469         (JSC::JSWeakSet::create):
3470         (JSC::JSWeakSet::weakMapData):
3471         (JSC::JSWeakSet::JSWeakSet):
3472         * runtime/WeakMapPrototype.cpp:
3473         (JSC::getWeakMapData):
3474         (JSC::protoFuncWeakMapDelete):
3475         (JSC::protoFuncWeakMapGet):
3476         (JSC::protoFuncWeakMapHas):
3477         * runtime/WeakSetConstructor.cpp: Added.
3478         (JSC::WeakSetConstructor::finishCreation):
3479         (JSC::callWeakSet):
3480         (JSC::constructWeakSet):
3481         (JSC::WeakSetConstructor::getConstructData):
3482         (JSC::WeakSetConstructor::getCallData):
3483         * runtime/WeakSetConstructor.h: Added.
3484         (JSC::WeakSetConstructor::create):
3485         (JSC::WeakSetConstructor::createStructure):
3486         (JSC::WeakSetConstructor::WeakSetConstructor):
3487         * runtime/WeakSetPrototype.cpp: Added.
3488         (JSC::WeakSetPrototype::finishCreation):
3489         (JSC::getWeakMapData):
3490         (JSC::protoFuncWeakSetDelete):
3491         (JSC::protoFuncWeakSetHas):
3492         (JSC::protoFuncWeakSetAdd):
3493         * runtime/WeakSetPrototype.h: Added.
3494         (JSC::WeakSetPrototype::create):
3495         (JSC::WeakSetPrototype::createStructure):
3496         (JSC::WeakSetPrototype::WeakSetPrototype):
3497         * tests/stress/weak-set-constructor-adder.js: Added.
3498         (WeakSet.prototype.add):
3499         * tests/stress/weak-set-constructor.js: Added.
3500
3501 2015-04-17  Alexey Proskuryakov  <ap@apple.com>
3502
3503         Remove unused BoundsCheckedPointer
3504         https://bugs.webkit.org/show_bug.cgi?id=143896
3505
3506         Reviewed by Geoffrey Garen.
3507
3508         * bytecode/SpeculatedType.cpp: The header was included here.
3509
3510 2015-04-17  Yusuke Suzuki  <utatane.tea@gmail.com>
3511
3512         [ES6] Fix name enumeration of static functions for Symbol constructor
3513         https://bugs.webkit.org/show_bug.cgi?id=143891
3514
3515         Reviewed by Geoffrey Garen.
3516
3517         Fix missing symbolPrototypeTable registration to the js class object.
3518         This patch fixes name enumeration of static functions (Symbol.key, Symbol.keyFor) for Symbol constructor.
3519
3520         * runtime/SymbolConstructor.cpp:
3521
3522 2015-04-17  Basile Clement  <basile_clement@apple.com>
3523
3524         Inline JSFunction allocation in DFG
3525         https://bugs.webkit.org/show_bug.cgi?id=143858
3526
3527         Reviewed by Filip Pizlo.
3528
3529         Followup to my previous patch which inlines JSFunction allocation when
3530         using FTL, now also enabled in DFG.
3531
3532         * dfg/DFGSpeculativeJIT.cpp:
3533         (JSC::DFG::SpeculativeJIT::compileNewFunction):
3534
3535 2015-04-16  Jordan Harband  <ljharb@gmail.com>
3536
3537         Number.parseInt is not === global parseInt in nightly r182673
3538         https://bugs.webkit.org/show_bug.cgi?id=143799
3539
3540         Reviewed by Darin Adler.
3541
3542         Ensuring parseInt === Number.parseInt, per spec
3543         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-number.parseint
3544
3545         * runtime/CommonIdentifiers.h:
3546         * runtime/JSGlobalObject.cpp:
3547         (JSC::JSGlobalObject::init):
3548         * runtime/JSGlobalObject.h:
3549         (JSC::JSGlobalObject::parseIntFunction):
3550         * runtime/NumberConstructor.cpp:
3551         (JSC::NumberConstructor::finishCreation):
3552
3553 2015-04-16  Mark Lam  <mark.lam@apple.com>
3554
3555         Gardening: fix CLOOP build after r182927.
3556
3557         Not reviewed.
3558
3559         * interpreter/StackVisitor.cpp:
3560         (JSC::StackVisitor::Frame::print):
3561
3562 2015-04-16  Basile Clement  <basile_clement@apple.com>
3563
3564         Inline JSFunction allocation in FTL
3565         https://bugs.webkit.org/show_bug.cgi?id=143851
3566
3567         Reviewed by Filip Pizlo.
3568
3569         JSFunction allocation is a simple operation that should be inlined when possible.
3570
3571         * ftl/FTLAbstractHeapRepository.h:
3572         * ftl/FTLLowerDFGToLLVM.cpp:
3573         (JSC::FTL::LowerDFGToLLVM::compileNewFunction):
3574         * runtime/JSFunction.h:
3575         (JSC::JSFunction::allocationSize):
3576
3577 2015-04-16  Mark Lam  <mark.lam@apple.com>
3578
3579         Add $vm debugging tool.
3580         https://bugs.webkit.org/show_bug.cgi?id=143809
3581
3582         Reviewed by Geoffrey Garen.
3583
3584         For debugging VM bugs, it would be useful to be able to dump VM data structures
3585         from JS code that we instrument.  To this end, let's introduce a
3586         JS_enableDollarVM option that, if true, installs an $vm property into each JS
3587         global object at creation time.  The $vm property refers to an object that
3588         provides a collection of useful utility functions.  For this initial
3589         implementation, $vm will have the following:
3590
3591             crash() - trigger an intentional crash.
3592
3593             dfgTrue() - returns true if the current function is DFG compiled, else returns false.
3594             jitTrue() - returns true if the current function is compiled by the baseline JIT, else returns false.
3595             llintTrue() - returns true if the current function is interpreted by the LLINT, else returns false.
3596
3597             gc() - runs a full GC.
3598             edenGC() - runs an eden GC.
3599
3600             codeBlockForFrame(frameNumber) - gets the codeBlock at the specified frame (0 = current, 1 = caller, etc).
3601             printSourceFor(codeBlock) - prints the source code for the codeBlock.
3602             printByteCodeFor(codeBlock) - prints the bytecode for the codeBlock.
3603
3604             print(str) - prints a string to dataLog output.
3605             printCallFrame() - prints the current CallFrame.
3606             printStack() - prints the JS stack.
3607             printInternal(value) - prints the JSC internal info for the specified value.
3608
3609         With JS_enableDollarVM=true, JS code can use the above functions like so:
3610
3611             $vm.print("Using $vm features\n");
3612
3613         * CMakeLists.txt:
3614         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3615         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3616         * JavaScriptCore.xcodeproj/project.pbxproj:
3617         * bytecode/CodeBlock.cpp:
3618         (JSC::CodeBlock::printCallOp):
3619         - FTL compiled functions don't like it when we try to compute the CallLinkStatus.
3620           Hence, we skip this step if we're dumping an FTL codeBlock.
3621
3622         * heap/Heap.cpp:
3623         (JSC::Heap::collectAndSweep):
3624         (JSC::Heap::collectAllGarbage): Deleted.
3625         * heap/Heap.h:
3626         (JSC::Heap::collectAllGarbage):
3627         - Add ability to do an Eden collection and sweep.
3628
3629         * interpreter/StackVisitor.cpp:
3630         (JSC::printIndents):
3631         (JSC::log):
3632         (JSC::logF):
3633         (JSC::StackVisitor::Frame::print):
3634         (JSC::jitTypeName): Deleted.
3635         (JSC::printif): Deleted.
3636         - Modernize the implementation of StackVisitor::Frame::print(), and remove some
3637           now redundant code.
3638         - Also fix it so that it downgrades gracefully when encountering inlined DFG
3639           and compiled FTL functions.
3640
3641         (DebugPrintFrameFunctor::DebugPrintFrameFunctor): Deleted.
3642         (DebugPrintFrameFunctor::operator()): Deleted.
3643         (debugPrintCallFrame): Deleted.
3644         (debugPrintStack): Deleted.
3645         - these have been moved into JSDollarVMPrototype.cpp. 
3646
3647         * interpreter/StackVisitor.h:
3648         - StackVisitor::Frame::print() is now enabled for release builds as well so that
3649           we can call it from $vm.
3650
3651         * runtime/JSGlobalObject.cpp:
3652         (JSC::JSGlobalObject::init):
3653         (JSC::JSGlobalObject::visitChildren):
3654         * runtime/JSGlobalObject.h:
3655         - Added the $vm instance to global objects conditional on the JSC_enableDollarVM
3656           option.
3657
3658         * runtime/Options.h:
3659         - Added the JSC_enableDollarVM option.
3660
3661         * tools/JSDollarVM.cpp: Added.
3662         * tools/JSDollarVM.h: Added.
3663         (JSC::JSDollarVM::createStructure):
3664         (JSC::JSDollarVM::create):
3665         (JSC::JSDollarVM::JSDollarVM):
3666
3667         * tools/JSDollarVMPrototype.cpp: Added.
3668         - This file contains 2 sets of functions:
3669
3670           a. a C++ implementation of debugging utility functions that are callable when
3671              doing debugging from lldb.  To the extent possible, these functions try to
3672              be cautious and not cause unintended crashes should the user call them with
3673              the wrong info.  Hence, they are designed to be robust rather than speedy.
3674
3675           b. the native implementations of JS functions in the $vm object.  Where there
3676              is overlapping functionality, these are built on top of the C++ functions
3677              above to do the work.
3678
3679           Note: it does not make sense for all of the $vm functions to have a C++
3680           counterpart for lldb debugging.  For example, the $vm.dfgTrue() function is
3681           only useful for JS code, and works via the DFG intrinsics mechanism.
3682           When doing debugging via lldb, the optimization level of the currently
3683           executing JS function can be gotten by dumping the current CallFrame instead.
3684
3685         (JSC::currentThreadOwnsJSLock):
3686         (JSC::ensureCurrentThreadOwnsJSLock):
3687         (JSC::JSDollarVMPrototype::addFunction):
3688         (JSC::functionCrash): - $vm.crash()
3689         (JSC::functionDFGTrue): - $vm.dfgTrue()
3690         (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
3691         (JSC::CallerFrameJITTypeFunctor::operator()):
3692         (JSC::CallerFrameJITTypeFunctor::jitType):
3693         (JSC::functionLLintTrue): - $vm.llintTrue()
3694         (JSC::functionJITTrue): - $vm.jitTrue()
3695         (JSC::gc):
3696         (JSC::functionGC): - $vm.gc()
3697         (JSC::edenGC):
3698         (JSC::functionEdenGC): - $vm.edenGC()
3699         (JSC::isValidCodeBlock):
3700         (JSC::codeBlockForFrame):
3701         (JSC::functionCodeBlockForFrame): - $vm.codeBlockForFrame(frameNumber)
3702         (JSC::codeBlockFromArg):
3703         (JSC::functionPrintSourceFor): - $vm.printSourceFor(codeBlock)
3704         (JSC::functionPrintByteCodeFor): - $vm.printBytecodeFor(codeBlock)
3705         (JSC::functionPrint): - $vm.print(str)
3706         (JSC::PrintFrameFunctor::PrintFrameFunctor):
3707         (JSC::PrintFrameFunctor::operator()):
3708         (JSC::printCallFrame):
3709         (JSC::printStack):
3710         (JSC::functionPrintCallFrame): - $vm.printCallFrame()
3711         (JSC::functionPrintStack): - $vm.printStack()
3712         (JSC::printValue):
3713         (JSC::functionPrintValue): - $vm.printValue()
3714         (JSC::JSDollarVMPrototype::finishCreation):
3715         * tools/JSDollarVMPrototype.h: Added.
3716         (JSC::JSDollarVMPrototype::create):
3717         (JSC::JSDollarVMPrototype::createStructure):
3718         (JSC::JSDollarVMPrototype::JSDollarVMPrototype):
3719
3720 2015-04-16  Geoffrey Garen  <ggaren@apple.com>
3721
3722         Speculative fix after r182915
3723         https://bugs.webkit.org/show_bug.cgi?id=143404
3724
3725         Reviewed by Alexey Proskuryakov.
3726
3727         * runtime/SymbolConstructor.h:
3728
3729 2015-04-16  Mark Lam  <mark.lam@apple.com>
3730
3731         Fixed some typos in a comment.
3732
3733         Not reviewed.
3734
3735         * dfg/DFGGenerationInfo.h:
3736
3737 2015-04-16  Yusuke Suzuki  <utatane.tea@gmail.com>
3738
3739         [ES6] Implement Symbol.for and Symbol.keyFor
3740         https://bugs.webkit.org/show_bug.cgi?id=143404
3741
3742         Reviewed by Geoffrey Garen.
3743
3744         This patch implements Symbol.for and Symbol.keyFor.
3745         SymbolRegistry maintains registered StringImpl* symbols.
3746         And to make this mapping enabled over realms,
3747         VM owns this mapping (not JSGlobalObject).
3748
3749         While there's Default AtomicStringTable per thread,
3750         SymbolRegistry should not exist over VMs.
3751         So everytime VM is created, SymbolRegistry is also created.
3752
3753         In SymbolRegistry implementation, we don't leverage WeakGCMap (or weak reference design).
3754         Theres are several reasons.
3755         1. StringImpl* which represents identity of Symbols is not GC-managed object.
3756            So we cannot use WeakGCMap directly.
3757            While Symbol* is GC-managed object, holding weak reference to Symbol* doesn't maintain JS symbols (exposed primitive values to users) liveness,
3758            because distinct Symbol* can exist.
3759            Distinct Symbol* means the Symbol* object that pointer value (Symbol*) is different from weakly referenced Symbol* but held StringImpl* is the same.
3760
3761         2. We don't use WTF::WeakPtr. If we add WeakPtrFactory into StringImpl's member, we can track StringImpl*'s liveness by WeakPtr.
3762            However there's problem about when we prune staled entries in SymbolRegistry.
3763            Since the memory allocated for the Symbol is typically occupied by allocated symbolized StringImpl*'s content,
3764            and it is not in GC-heap.
3765            While heavily registering Symbols and storing StringImpl* into SymbolRegistry, Heap's EdenSpace is not so occupied.
3766            So GC typically attempt to perform EdenCollection, and it doesn't call WeakGCMap's pruleStaleEntries callback.
3767            As a result, before pruning staled entries in SymbolRegistry, fast malloc-ed memory fills up the system memory.
3768
3769         So instead of using Weak reference, we take relatively easy design.
3770         When we register symbolized StringImpl* into SymbolRegistry, symbolized StringImpl* is aware of that.
3771         And when destructing it, it removes its reference from SymbolRegistry as if atomic StringImpl do so with AtomicStringTable.
3772
3773         * CMakeLists.txt:
3774         * DerivedSources.make:
3775         * runtime/SymbolConstructor.cpp:
3776         (JSC::SymbolConstructor::getOwnPropertySlot):
3777         (JSC::symbolConstructorFor):
3778         (JSC::symbolConstructorKeyFor):
3779         * runtime/SymbolConstructor.h:
3780         * runtime/VM.cpp:
3781         * runtime/VM.h:
3782         (JSC::VM::symbolRegistry):
3783         * tests/stress/symbol-registry.js: Added.
3784         (test):
3785
3786 2015-04-16  Yusuke Suzuki  <utatane.tea@gmail.com>
3787
3788         [ES6] Use specific functions for @@iterator functions
3789         https://bugs.webkit.org/show_bug.cgi?id=143838
3790
3791         Reviewed by Geoffrey Garen.
3792
3793         In ES6, some methods are defined with the different names.
3794
3795         For example,
3796
3797         Map.prototype[Symbol.iterator] === Map.prototype.entries
3798         Set.prototype[Symbol.iterator] === Set.prototype.values
3799         Array.prototype[Symbol.iterator] === Array.prototype.values
3800         %Arguments%[Symbol.iterator] === Array.prototype.values
3801
3802         However, current implementation creates different function objects per name.
3803         This patch fixes it by setting the object that is used for the other method to @@iterator.
3804         e.g. Setting Array.prototype.values function object to Array.prototype[Symbol.iterator].
3805
3806         And we drop Arguments' iterator implementation and replace Argument[@@iterator] implementation
3807         with Array.prototype.values to conform to the spec.
3808
3809         * CMakeLists.txt:
3810         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3811         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3812         * JavaScriptCore.xcodeproj/project.pbxproj:
3813         * inspector/JSInjectedScriptHost.cpp:
3814         (Inspector::JSInjectedScriptHost::subtype):
3815         (Inspector::JSInjectedScriptHost::getInternalProperties):
3816         (Inspector::JSInjectedScriptHost::iteratorEntries):
3817         * runtime/ArgumentsIteratorConstructor.cpp: Removed.
3818         * runtime/ArgumentsIteratorConstructor.h: Removed.
3819         * runtime/ArgumentsIteratorPrototype.cpp: Removed.
3820         * runtime/ArgumentsIteratorPrototype.h: Removed.
3821         * runtime/ArrayPrototype.cpp:
3822         (JSC::ArrayPrototype::finishCreation):
3823         * runtime/ArrayPrototype.h:
3824         * runtime/ClonedArguments.cpp:
3825         (JSC::ClonedArguments::getOwnPropertySlot):
3826         (JSC::ClonedArguments::put):
3827         (JSC::ClonedArguments::deleteProperty):
3828         (JSC::ClonedArguments::defineOwnProperty):
3829         (JSC::ClonedArguments::materializeSpecials):
3830         * runtime/ClonedArguments.h:
3831         * runtime/CommonIdentifiers.h:
3832         * runtime/DirectArguments.cpp:
3833         (JSC::DirectArguments::overrideThings):
3834         * runtime/GenericArgumentsInlines.h:
3835         (JSC::GenericArguments<Type>::getOwnPropertySlot):
3836         (JSC::GenericArguments<Type>::getOwnPropertyNames):
3837         (JSC::GenericArguments<Type>::put):
3838         (JSC::GenericArguments<Type>::deleteProperty):
3839         (JSC::GenericArguments<Type>::defineOwnProperty):
3840         * runtime/JSArgumentsIterator.cpp: Removed.
3841         * runtime/JSArgumentsIterator.h: Removed.
3842         * runtime/JSGlobalObject.cpp:
3843         (JSC::JSGlobalObject::init):
3844         (JSC::JSGlobalObject::visitChildren):
3845         * runtime/JSGlobalObject.h:
3846         (JSC::JSGlobalObject::arrayProtoValuesFunction):
3847         * runtime/MapPrototype.cpp:
3848         (JSC::MapPrototype::finishCreation):
3849         * runtime/ScopedArguments.cpp:
3850         (JSC::ScopedArguments::overrideThings):
3851         * runtime/SetPrototype.cpp:
3852         (JSC::SetPrototype::finishCreation):
3853         * tests/stress/arguments-iterator.js: Added.
3854         (test):
3855         (testArguments):
3856         * tests/stress/iterator-functions.js: Added.
3857         (test):
3858         (argumentsTests):
3859
3860 2015-04-14  Mark Lam  <mark.lam@apple.com>
3861
3862         Add JSC_functionOverrides=<overrides file> debugging tool.
3863         https://bugs.webkit.org/show_bug.cgi?id=143717
3864
3865         Reviewed by Geoffrey Garen.
3866
3867         This tool allows us to do runtime replacement of function bodies with alternatives
3868         for debugging purposes.  For example, this is useful when we need to debug VM bugs
3869         which manifest in scripts executing in webpages downloaded from remote servers
3870         that we don't control.  The tool allows us to augment those scripts with logging
3871         or test code to help isolate the bugs.
3872
3873         This tool works by substituting the SourceCode at FunctionExecutable creation
3874         time.  It identifies which SourceCode to substitute by comparing the source
3875         string against keys in a set of key value pairs.
3876