[JSC] Use StringBuilder::appendNumber() instead of String::number()
https://bugs.webkit.org/show_bug.cgi?id=96236

Reviewed by Benjamin Poulain.

* API/JSContextRef.cpp:
(JSContextCreateBacktrace):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128091 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] gradient-with-scaled-ancestor.html rebaseline
https://bugs.webkit.org/show_bug.cgi?id=96110

Patch by Alex Sakhartchouk <alexst@chromium.org> on 2012-09-10
Reviewed by Adrienne Walker.

Fixed a bug in the test, rebaselining the results at proper resolution.

* platform/chromium-linux-x86/fast/hidpi/gradient-with-scaled-ancestor-expected.png: Removed.
* platform/chromium-linux/fast/hidpi/gradient-with-scaled-ancestor-expected.png:
* platform/chromium-mac-snowleopard/fast/hidpi/gradient-with-scaled-ancestor-expected.png:
* platform/chromium-mac/fast/hidpi/gradient-with-scaled-ancestor-expected.png:
* platform/chromium-win-xp/fast/hidpi/gradient-with-scaled-ancestor-expected.png: Removed.
* platform/chromium-win/fast/hidpi/gradient-with-scaled-ancestor-expected.png:
* platform/chromium/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128092 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebKit/chromium: [chromium] Add unused GestureTapCancel
https://bugs.webkit.org/show_bug.cgi?id=96183

Patch by Rick Byers <rbyers@chromium.org> on 2012-09-10
Reviewed by Adam Barth.

This adds a new 'tap cancel' gesture type.  This is temporarily unused,
so that we can change chromium to start sending the gesture type
without breaking anything.

* public/WebInputEvent.h:
* src/PageWidgetDelegate.cpp:
(WebKit::PageWidgetDelegate::handleInputEvent):
* src/WebInputEventConversion.cpp:
(WebKit::PlatformGestureEventBuilder::PlatformGestureEventBuilder):
* src/WebPopupMenuImpl.cpp:
(WebKit::WebPopupMenuImpl::handleInputEvent):
* src/WebViewImpl.cpp:
(WebKit::WebViewImpl::handleGestureEvent):

Tools: Add handling of new GestureTapCancel in DRT

https://bugs.webkit.org/show_bug.cgi?id=96183

Patch by Rick Byers <rbyers@chromium.org> on 2012-09-10
Reviewed by Adam Barth.

* DumpRenderTree/chromium/TestWebPlugin.cpp:
(TestWebPlugin::handleInputEvent):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128093 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[V8] Constructors try to handle errors that cannot occur
https://bugs.webkit.org/show_bug.cgi?id=96304

Patch by Adam Barth <abarth@chromium.org> on 2012-09-10
Reviewed by Kentaro Hara.

There's no reason for constructors to indirect through the Frame. Now
that we can reliably get the Document from the v8::Context, we can just
grab it without worrying about handling error conditions related to not
being able to find the Document.

* bindings/scripts/CodeGeneratorV8.pm:
(GenerateNamedConstructorCallback):
* bindings/scripts/test/V8/V8TestNamedConstructor.cpp:
(WebCore::V8TestNamedConstructorConstructorCallback):
* bindings/v8/custom/V8AudioContextCustom.cpp:
(WebCore::V8AudioContext::constructorCallback):
* bindings/v8/custom/V8HTMLImageElementConstructor.cpp:
(WebCore::v8HTMLImageElementConstructorCallback):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128094 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[V8] V8HTMLDocument::write and friends should not indirect through Frame
https://bugs.webkit.org/show_bug.cgi?id=96289

Patch by Adam Barth <abarth@chromium.org> on 2012-09-10
Reviewed by Eric Seidel.

There is no reason why document.write and friends need to indirect
through the Frame to find the active document. This patch makes these
functions work the same as the JSC versions.

* bindings/v8/BindingState.cpp:
* bindings/v8/BindingState.h:
    - This patch removes the last callers of activeFrame, so we can
      remove the function entirely.
* bindings/v8/custom/V8HTMLDocumentCustom.cpp:
(WebCore::V8HTMLDocument::writeCallback):
(WebCore::V8HTMLDocument::writelnCallback):
(WebCore::V8HTMLDocument::openCallback):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128095 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Refactored op_tear_off* to support activations that don't allocate space for 'arguments'
https://bugs.webkit.org/show_bug.cgi?id=96231

Reviewed by Gavin Barraclough.

This is a step toward smaller activations.

As a side-effect, this patch eliminates a load and branch from the hot path
of activation tear-off by moving it to the cold path of arguments tear-off. Our
optimizing assumptions are that activations are common and that reifying the
arguments object is less common.

* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dump):
* bytecode/Opcode.h:
(JSC::padOpcodeName): Updated for new opcode lengths.

* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::addConstantValue): Added support for JSValue()
in the bytecode, which we use when we have 'arguments' but no activation.

(JSC::BytecodeGenerator::emitReturn): Always emit tear_off_arguments
if we've allocated the arguments registers. This allows tear_off_activation
not to worry about the arguments object anymore.

Also, pass the activation and arguments values directly to these opcodes
instead of requiring the opcodes to infer the values through special
registers. This gives us more flexibility to move or eliminate registers.

* dfg/DFGArgumentsSimplificationPhase.cpp:
(JSC::DFG::ArgumentsSimplificationPhase::run):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGNode.h:
(Node): Updated for new opcode lengths.

* dfg/DFGOperations.cpp: Activation tear-off doesn't worry about the
arguments object anymore. If 'arguments' is in use and reified, it's
responsible for aliasing back to the activation object in tear_off_arguments.

* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile): Don't pass the arguments object to
activation tear-off; do pass the activation object to arguments tear-off.

* interpreter/Interpreter.cpp:
(JSC::Interpreter::privateExecute): Ditto.

* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_tear_off_activation):
(JSC::JIT::emit_op_tear_off_arguments):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_tear_off_activation):
(JSC::JIT::emit_op_tear_off_arguments):
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm: Same change in a few more execution engines.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128096 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed fix of webkit-lint for Chromium gardening

* platform/chromium/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128097 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Silence a warning when running update-webkit-localizable-strings
https://bugs.webkit.org/show_bug.cgi?id=96307

Reviewed by John Sullivan.

Since both the blockedPluginByContentSecurityPolicyText and insecurePluginVersionText strings use exact the same wording,
use WEB_UI_STRING_KEY to indicate that they are different.

* English.lproj/Localizable.strings:
Update the localizable strings file.

* platform/LocalizedStrings.cpp:
(WebCore::blockedPluginByContentSecurityPolicyText):
(WebCore::insecurePluginVersionText):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128098 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Update the css3/filters test expectations to match the bots.
90+ of these tests never failed, so adding the whole css3/filters
directory was incorrect.
* platform/chromium/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128099 268f45cc-cd09-0410-ab3c-d52691b4dbfc