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