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