Remove these supressions now that we've reverted http://trac.webkit.org/changeset/144126.

* platform/chromium/TestExpectations:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144343 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Remove the quirk margin bits from RenderObject and put them back in RenderBlock.
https://bugs.webkit.org/show_bug.cgi?id=111089

Reviewed by Dan Bernstein.

This patch removes the marginBeforeQuirk and marginAfterQuirk bits from RenderObject
and puts them into RenderBlock instead. I also did some renaming and clean-up after
moving them, e.g., to hasMarginBeforeQuirk and hasMarginAfterQuirk.
        
Even though it's pretty irrelevant, I also made the code writing-mode-correct so that
the correct child margin quirk is propagated across differing writing mode
boundaries.

* rendering/RenderBlock.cpp:
(WebCore::RenderBlock::MarginInfo::MarginInfo):
(WebCore::RenderBlock::RenderBlock):
(WebCore::RenderBlock::layoutBlock):
(WebCore::RenderBlock::collapseMargins):
(WebCore::RenderBlock::marginBeforeEstimateForChild):
(WebCore::RenderBlock::setCollapsedBottomMargin):
(WebCore::RenderBlock::handleAfterSideOfBlock):
(WebCore::RenderBlock::hasMarginBeforeQuirk):
(WebCore):
(WebCore::RenderBlock::hasMarginAfterQuirk):
* rendering/RenderBlock.h:
(WebCore::RenderBlock::setHasMarginBeforeQuirk):
(WebCore::RenderBlock::setHasMarginAfterQuirk):
(RenderBlock):
(WebCore::RenderBlock::hasMarginBeforeQuirk):
(WebCore::RenderBlock::hasMarginAfterQuirk):
(MarginInfo):
(WebCore::RenderBlock::MarginInfo::setHasMarginBeforeQuirk):
(WebCore::RenderBlock::MarginInfo::setHasMarginAfterQuirk):
(WebCore::RenderBlock::MarginInfo::hasMarginBeforeQuirk):
(WebCore::RenderBlock::MarginInfo::hasMarginAfterQuirk):
* rendering/RenderObject.h:
(RenderObject):
(WebCore::RenderObject::RenderObjectBitfields::RenderObjectBitfields):
(RenderObjectBitfields):
* rendering/style/RenderStyle.h:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144344 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Chromium] Unreviewed gardening, update expectation

* platform/chromium/TestExpectations: Add Win modifier for compositing/rtl/rtl-iframe-fixed-overflow-scrolled.html
    and remove modifiers for fast/forms/textarea/textarea-state-restore.html


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144345 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Crash in JSC::MarkedBlock::FreeList JSC::MarkedBlock::sweepHelper
https://bugs.webkit.org/show_bug.cgi?id=111059

Reviewed by Ryosuke Niwa.

Sometimes C++'s implicit operator conversion rules suck.
Add explicit operator== and !=.

* wtf/FastMalloc.cpp:
(WTF::HardenedSLL::operator!=):
(WTF::HardenedSLL::operator==):
(HardenedSLL):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144346 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Re-baselining expected pixels for fast/borders/border-radius-percent.html on linux
https://bugs.webkit.org/show_bug.cgi?id=110889

Unreviewed

* TestExpectations:
* platform/chromium-linux/fast/borders/border-radius-percent-expected.png:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144349 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Focus ring for a child layer is incorrectly offset by ancestor composited layer's position
https://bugs.webkit.org/show_bug.cgi?id=110895

Reviewed by Simon Fraser.

Source/WebCore:

Test: compositing/sub-layer-focus-ring.html

The problem occurs in RenderBlock::addFocusRingRects() where the absolute position of a sub-layer is used to calculate the focus ring rect of the layer.
Should use the relative position to the current paintContainer instead.

To fix the issue:
- RenderLayer passes LayerPaintingInfo.rootLayer to PaintInfo.paintContainer
- Let RenderObject::paintFocusRing() and RenderObject::paintOutline() take PaintInfo instead of GraphicsContext* so that the paintContainer can be passed
- RenderBlock::addFocusRingRects() uses localToContainerPoint(FloatPoint(), paintContainer) instead of localToAbsolute() to calculate the focus ring rect of a sublayer.

* rendering/PaintInfo.h:
(WebCore):
(WebCore::PaintInfo::PaintInfo): Add a field paintContainer (the RenderLayerModelObject which originates the current painting)
(PaintInfo):
* rendering/RenderBlock.cpp:
(WebCore::RenderBlock::paintObject):
(WebCore::RenderBlock::paintContinuationOutlines):
(WebCore::RenderBlock::addFocusRingRects): Use the added paintContainer parameter to calculate the relative offset of the child layer.
* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::paintBackgroundForFragments): Pass LayerPaintingInfo.rootLayer to PaintInfo.paintContainer.
(WebCore::RenderLayer::paintForegroundForFragmentsWithPhase): Ditto.
(WebCore::RenderLayer::paintOutlineForFragments): Ditto.
(WebCore::RenderLayer::paintMaskForFragments): Ditto.
* rendering/RenderLayer.cpp:
* rendering/RenderObject.cpp:
(WebCore::RenderObject::paintFocusRing): Now takes PaintInfo instead of GraphicsContext*. Pass paintInfo.paintContainer to addFocusRingRects().
(WebCore::RenderObject::paintOutline): Now takes PaintInfo instead of GraphicsContext*.
(WebCore::RenderObject::absoluteFocusRingQuads):
* rendering/RenderObject.h:
(WebCore::RenderObject::addFocusRingRects): Add paintContainer parameter.

LayoutTests:

New ref test for the bug.

* compositing/sub-layer-focus-ring-expected.html: Added.
* compositing/sub-layer-focus-ring.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144350 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Implement more StorageAreaProxy member functions
https://bugs.webkit.org/show_bug.cgi?id=111103

Reviewed by Sam Weinig.

Source/WebCore:

Export two more StorageMap symbols required by WebKit2.

* WebCore.exp.in:

Source/WebKit2:

* Shared/SecurityOriginData.cpp:
(WebKit::SecurityOriginData::securityOrigin):
* Shared/SecurityOriginData.h:
Add helper to create a WebCore::SecurityOrigin from a SecurityOriginData object.

* WebProcess/Storage/StorageAreaProxy.cpp:
(WebKit::StorageAreaProxy::key):
Fill the storage map and call through to StorageMap::key.

(WebKit::StorageAreaProxy::contains):
Fill the storage map and call through to StorageMap::contains.

(WebKit::StorageAreaProxy::memoryBytesUsedByCache):
Return 0; this matches StorageAreaImpl.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144351 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION: INPUT_MULTIPLE_FIELDS_UI: Changing CSS display property on input[type=date] unexpectedly makes another line for ::-webkit-calendar-picker-indicator
https://bugs.webkit.org/show_bug.cgi?id=110974

Reviewed by Kentaro Hara.

Source/WebCore:

Input elements with the multiple fields UI require flexible box
layout.
- If display:inline or display:inline-block is specified, we
  replace it with display:inline-flex.
- If display:block is specified, we replace it with
  display:flex.
- If other display value is specified, we use it as is, but it
  won't wrap inside an input element because we have
  display:inline-block for ::-webkit-calendar-pixker-indicaotor.

r144184 was incomplete. It avoided the wrapping issue, but it
didn't make spin buttons and calendar arrows right-aligned.

Tests: Update fast/forms/date/date-apparance-basic.html

* css/html.css:
(input::-webkit-calendar-picker-indicator):
Add display:inline-block in orde to avoid line-wrapping.
* html/HTMLInputElement.cpp:
(WebCore::HTMLInputElement::customStyleForRenderer):
Move the code to BaseMultipleFieldsDateAndTimeInputType::customStyleForRenderer.
* html/InputType.cpp:
(WebCore::InputType::customStyleForRenderer): Added.
* html/InputType.h:
(InputType): Add customStyleForRenderer, and remove
shouldApplyLocaleDirection.
* html/BaseMultipleFieldsDateAndTimeInputType.cpp:
(WebCore::BaseMultipleFieldsDateAndTimeInputType::customStyleForRenderer):
Moved the code from HTMLInputElement::customStyleForRenderer, and
add display property updatting code.
* html/BaseMultipleFieldsDateAndTimeInputType.h:
(BaseMultipleFieldsDateAndTimeInputType):
Add customStyleForRenderer, and remove shouldApplyLocaleDirection.

LayoutTests:

* fast/forms/date/date-appearance-basic-expected.txt:
* fast/forms/date/date-appearance-basic.html:
* platform/chromium-mac/fast/forms/date/date-appearance-basic-expected.png:
* platform/chromium/TestExpectations:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144352 268f45cc-cd09-0410-ab3c-d52691b4dbfc
        Create BlobRegistry through a strategy
        https://bugs.webkit.org/show_bug.cgi?id=111100

        Reviewed by Sam Weinig.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * Target.pri:
        * WebCore.gypi:
        * WebCore.vcproj/WebCore.vcproj:
        * WebCore.vcxproj/WebCore.vcxproj:
        * WebCore.vcxproj/WebCore.vcxproj.filters:
        * WebCore.xcodeproj/project.pbxproj:
        Added BlobRegistry.cpp.

        * WebCore.exp.in:
        * loader/LoaderStrategy.cpp:
        (WebCore::LoaderStrategy::createBlobRegistry):
        * loader/LoaderStrategy.h:
        Addxed a function to create BlobRegistry, with default implementation being
        in-process WebKit1 one.

        * platform/network/BlobData.h: Added ENABLE(BLOB).

        * platform/network/BlobRegistry.cpp: Added. Moved singleton to a separate file.
        * platform/network/BlobRegistry.h: Made destructor non-inline. Cleaned up includes.

        * platform/network/BlobRegistryImpl.cpp:
        * platform/network/BlobRegistryImpl.h:
        Cleaned up includes, made functions that are only called through base class private.
        Added ENABLE(BLOB).

        * platform/network/BlobStorageData.h: Added ENABLE(BLOB).

        * platform/network/FormData.cpp:
        (WebCore::appendBlobResolved): Check blob registry type before upcasting. It's a
        public function, and we should not depend on high level understanding of process
        model to prove that the cast is safe.

        * platform/network/ResourceHandle.cpp:
        * platform/network/cf/FormDataStreamCFNet.cpp:
        * platform/network/mac/ResourceHandleMac.mm:
        Cleaned up includes.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144353 268f45cc-cd09-0410-ab3c-d52691b4dbfc
        Create BlobRegistry through a strategy
        https://bugs.webkit.org/show_bug.cgi?id=111100

        Chromium build fix.

        * platform/network/BlobRegistry.cpp: Use destructor for chromium too.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144354 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[BlackBerry] Maintain the directionality of the selection after modifying the selection using key events.
https://bugs.webkit.org/show_bug.cgi?id=111078

Reviewed by Yong Li.

PR 295224.

When using the key navigation to modify the selection, reset the
directionality of the selection to the original to prevent
changing the anchor.

Reviewed Internally by Nima Ghanavatian.

* WebKitSupport/SelectionHandler.cpp:
(BlackBerry::WebKit::SelectionHandler::updateOrHandleInputSelection):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144355 268f45cc-cd09-0410-ab3c-d52691b4dbfc
CodeBlock::valueProfile() has a bogus assertion
https://bugs.webkit.org/show_bug.cgi?id=111106
<rdar://problem/13131427>

Reviewed by Mark Hahnenberg.
        
This was just a bad assertion: m_bytecodeOffset == -1 means that the value profile is constructed but not initialized.
ValueProfile constructs itself in a safe way; you can call any method you want on a constructed but not initialized
ValueProfile. CodeBlock first constructs all ValueProfiles (by growing the ValueProfile vector) and then initializes
their m_bytecodeOffset later. This is necessary because the initialization is linking bytecode instructions to their
ValueProfiles, so at that point we don't want the ValueProfile vector to resize, which implies that we want all of
them to already be constructed. A GC can happen during this phase, and the GC may want to walk all ValueProfiles.
This is safe, but one of the ValueProfile getters (CodeBlock::valueProfile()) was asserting that any value profile
you get has had its m_bytecodeOffset initialized. This need not be the case and nothing will go wrong if it isn't.

The solution is to remove the assertion, which I believe was put there to ensure that my m_valueProfiles refactoring
a long time ago was sound: it used to be that a ValueProfile with m_bytecodeOffset == -1 was an argument profile; now
all argument profiles are in m_argumentValueProfiles instead. I think it's safe to say that this refactoring was done
soundly since it was a long time ago. So we should kill the assertion - I don't see an easy way to make the assertion
sound with respect to the GC-during-CodeBlock-construction issue, and I don't believe that the assertion is buying us
anything at this point.

* bytecode/CodeBlock.h:
(JSC::CodeBlock::valueProfile):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144356 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[EFL][WebGL] Enable compositing/webgl/webgl-reflection.html.
https://bugs.webkit.org/show_bug.cgi?id=110688

Patch by Kondapally Kalyan <kalyan.kondapally@intel.com> on 2013-02-28
Reviewed by Laszlo Gombos.

This patch adds platform specific test expectation files for the
test and enables it for efl port.

* platform/efl/TestExpectations:
* platform/efl/compositing/webgl/webgl-reflection-expected.png: Added.
* platform/efl/compositing/webgl/webgl-reflection-expected.txt: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144357 268f45cc-cd09-0410-ab3c-d52691b4dbfc
EXT_draw_buffers needs implementation
https://bugs.webkit.org/show_bug.cgi?id=109331

Reviewed by Kenneth Russell.

Source/Platform: 

Add EXT_draw_buffers support for chromium port.

* chromium/public/WebGraphicsContext3D.h:
(WebGraphicsContext3D):
(WebKit::WebGraphicsContext3D::drawBuffersEXT):

Source/WebCore: 

This patch adds support for EXT_draw_buffers for WebGL.
mac OpenGL port is passing khronos WebGL conformance test with this patch. OpenGL ES port implementation isn't added in this patch.
Also, it has the WebKit side support for chromium port, but pending command buffer implementation.

Besides the basic extension implementation, we also added drawBuffers() wrapper to work around a mac driver bug: i.e., do not enable a buffer if there is no attachment added.

* CMakeLists.txt:
* DerivedSources.make:
* DerivedSources.pri:
* GNUmakefile.list.am:
* Target.pri:
* WebCore.gypi:
* WebCore.xcodeproj/project.pbxproj:
* bindings/js/JSWebGLRenderingContextCustom.cpp:
(WebCore::toJS):
* bindings/v8/V8Binding.h:
(WebCore):
(WebCore::toInt32):
(WebCore::toUInt32):
(WebCore::toFloat):
(WebCore::toInt64):
* bindings/v8/custom/V8WebGLRenderingContextCustom.cpp:
(WebCore::toV8Object):
* html/canvas/EXTDrawBuffers.cpp: Added.
(WebCore):
(WebCore::EXTDrawBuffers::EXTDrawBuffers):
(WebCore::EXTDrawBuffers::~EXTDrawBuffers):
(WebCore::EXTDrawBuffers::getName):
(WebCore::EXTDrawBuffers::create):
(WebCore::EXTDrawBuffers::supported):
(WebCore::EXTDrawBuffers::drawBuffersEXT):
* html/canvas/EXTDrawBuffers.h: Added.
(WebCore):
(EXTDrawBuffers):
* html/canvas/EXTDrawBuffers.idl: Added.
* html/canvas/WebGLExtension.h:
* html/canvas/WebGLFramebuffer.cpp:
(WebCore::WebGLFramebuffer::setAttachmentForBoundFramebuffer):
(WebCore::WebGLFramebuffer::removeAttachmentFromBoundFramebuffer):
(WebCore::WebGLFramebuffer::drawBuffers):
(WebCore):
(WebCore::WebGLFramebuffer::drawBuffersIfNecessary):
* html/canvas/WebGLFramebuffer.h:
(WebGLFramebuffer):
* html/canvas/WebGLRenderingContext.cpp:
(WebCore):
(WebCore::WebGLRenderingContext::initializeNewContext):
(WebCore::WebGLRenderingContext::framebufferRenderbuffer):
(WebCore::WebGLRenderingContext::getExtension):
(WebCore::WebGLRenderingContext::getParameter):
(WebCore::WebGLRenderingContext::getSupportedExtensions):
(WebCore::WebGLRenderingContext::validateFramebufferFuncParameters):
(WebCore::WebGLRenderingContext::getMaxDrawBuffers):
(WebCore::WebGLRenderingContext::getMaxColorAttachments):
* html/canvas/WebGLRenderingContext.h:
(WebCore):
(WebGLRenderingContext):
* platform/chromium/support/Extensions3DChromium.cpp:
(WebCore::Extensions3DChromium::drawBuffersEXT):
(WebCore):
* platform/graphics/Extensions3D.h:
(Extensions3D):
* platform/graphics/GraphicsContext3D.cpp:
(WebCore::GraphicsContext3D::getClearBitsByAttachmentType):
* platform/graphics/chromium/Extensions3DChromium.h:
(Extensions3DChromium):
* platform/graphics/opengl/Extensions3DOpenGL.cpp:
(WebCore::Extensions3DOpenGL::supportsExtension):
(WebCore::Extensions3DOpenGL::drawBuffersEXT):
(WebCore):
* platform/graphics/opengl/Extensions3DOpenGL.h:
(Extensions3DOpenGL):
* platform/graphics/opengl/Extensions3DOpenGLCommon.cpp:
(WebCore::Extensions3DOpenGLCommon::ensureEnabled):
* platform/graphics/opengl/Extensions3DOpenGLCommon.h:
(Extensions3DOpenGLCommon):
* platform/graphics/opengl/Extensions3DOpenGLES.cpp:
(WebCore::Extensions3DOpenGLES::drawBuffersEXT):
(WebCore):
(WebCore::Extensions3DOpenGLES::supportsExtension):
* platform/graphics/opengl/Extensions3DOpenGLES.h:
(Extensions3DOpenGLES):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144358 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[texmap] Remove redundant defines on TextureMapperGL
https://bugs.webkit.org/show_bug.cgi?id=111090

Reviewed by Antonio Gomes.

driverSupportsSubImage() already uses OpenGL ES defines to return
correct support, thus no need for these additional defines.

No behavior changes, thus covered by existing tests.

* platform/graphics/texmap/TextureMapperGL.cpp:
(WebCore::BitmapTextureGL::updateContentsNoSwizzle):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144359 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Meta referrer isn't honored for window.open
https://bugs.webkit.org/show_bug.cgi?id=111076

Reviewed by Adam Barth.

Source/WebCore:

Test: http/tests/security/referrer-policy-window-open.html

* loader/FrameLoader.cpp:
(WebCore::FrameLoader::urlSelected): loadFrameRequest() will set the correct referrer
(WebCore::createWindow): This code is required for the inspector which doesn't set the referrer
* page/DOMWindow.cpp:
(WebCore::DOMWindow::createWindow):

LayoutTests:

* http/tests/security/referrer-policy-window-open-expected.txt: Added.
* http/tests/security/referrer-policy-window-open.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144360 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Update my IRC nick

Unreviewed.

* Scripts/webkitpy/common/config/committers.py:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144361 268f45cc-cd09-0410-ab3c-d52691b4dbfc
It should be easy to determine if a DFG node exits forward or backward when doing type checks
https://bugs.webkit.org/show_bug.cgi?id=111102

Reviewed by Mark Hahnenberg.
        
This adds a NodeExitsForward flag, which tells you the exit directionality of
type checks performed by the node. Even if you convert the node to a Phantom
and use the Edge UseKind for type checks, you'll still get the same exit
directionality that the original node would have wanted.

* dfg/DFGArgumentsSimplificationPhase.cpp:
(JSC::DFG::ArgumentsSimplificationPhase::run):
* dfg/DFGArrayifySlowPathGenerator.h:
(JSC::DFG::ArrayifySlowPathGenerator::ArrayifySlowPathGenerator):
* dfg/DFGCFGSimplificationPhase.cpp:
(JSC::DFG::CFGSimplificationPhase::run):
(JSC::DFG::CFGSimplificationPhase::mergeBlocks):
* dfg/DFGCPSRethreadingPhase.cpp:
(JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
* dfg/DFGCSEPhase.cpp:
(JSC::DFG::CSEPhase::setReplacement):
(JSC::DFG::CSEPhase::eliminate):
(JSC::DFG::CSEPhase::performNodeCSE):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::checkArray):
* dfg/DFGNode.h:
(Node):
(JSC::DFG::Node::setOpAndDefaultNonExitFlags):
(JSC::DFG::Node::convertToPhantom):
* dfg/DFGNodeFlags.cpp:
(JSC::DFG::nodeFlagsAsString):
* dfg/DFGNodeFlags.h:
(DFG):
* dfg/DFGNodeType.h:
(DFG):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::backwardSpeculationCheck):
(DFG):
(JSC::DFG::SpeculativeJIT::speculationCheck):
(JSC::DFG::SpeculativeJIT::speculationWatchpoint):
(JSC::DFG::SpeculativeJIT::forwardSpeculationCheck):
(JSC::DFG::SpeculativeJIT::backwardTypeCheck):
(JSC::DFG::SpeculativeJIT::typeCheck):
(JSC::DFG::SpeculativeJIT::forwardTypeCheck):
(JSC::DFG::SpeculativeJIT::fillStorage):
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::checkArgumentTypes):
(JSC::DFG::SpeculativeJIT::compileValueToInt32):
(JSC::DFG::SpeculativeJIT::compileInt32ToDouble):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
(JSC::DFG::SpeculateIntegerOperand::SpeculateIntegerOperand):
(JSC::DFG::SpeculateIntegerOperand::gpr):
(SpeculateIntegerOperand):
(JSC::DFG::SpeculateDoubleOperand::SpeculateDoubleOperand):
(JSC::DFG::SpeculateDoubleOperand::fpr):
(SpeculateDoubleOperand):
(JSC::DFG::SpeculateCellOperand::SpeculateCellOperand):
(JSC::DFG::SpeculateCellOperand::gpr):
(SpeculateCellOperand):
(JSC::DFG::SpeculateBooleanOperand::SpeculateBooleanOperand):
(JSC::DFG::SpeculateBooleanOperand::gpr):
(SpeculateBooleanOperand):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
(JSC::DFG::SpeculativeJIT::fillSpeculateInt):
(JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict):
(JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
(JSC::DFG::SpeculativeJIT::fillSpeculateCell):
(JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
(JSC::DFG::SpeculativeJIT::fillSpeculateInt):
(JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict):
(JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
(JSC::DFG::SpeculativeJIT::fillSpeculateCell):
(JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
(JSC::DFG::SpeculativeJIT::compile):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144362 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge more methods on PerfTest
https://bugs.webkit.org/show_bug.cgi?id=111030

Reviewed by Dirk Pranke.

Merged parse_output into _run_with_driver as it was the only caller. Also merged _should_ignore_line_in_stderr
and _should_ignore_line_in_parser_test_result into _filter_output since it was their only caller.

This makes the control flow a lot more comprehensible.

* Scripts/webkitpy/performance_tests/perftest.py:
(PerfTest._run_with_driver):
(PerfTest._should_ignore_line):
(PerfTest._filter_output):

* Scripts/webkitpy/performance_tests/perftest_unittest.py:
(TestPerfTest._assert_results_are_correct):
(test_ignored_stderr_lines):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144363 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed build fix for Windows. Make sure the new bits are unsigned and not bools.

* rendering/RenderBlock.h:



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