Stub out MemoryPressureHandler::ReliefLogger on older OS X'es.

* platform/cocoa/MemoryPressureHandlerCocoa.mm:
(WebCore::MemoryPressureHandler::ReliefLogger::platformLog):
(WebCore::MemoryPressureHandler::ReliefLogger::platformMemoryUsage):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@167454 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Prediction propagator should correctly model Int52s flowing through arguments
https://bugs.webkit.org/show_bug.cgi?id=131822
<rdar://problem/16641408>

Reviewed by Oliver Hunt.

* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* tests/stress/int52-argument.js: Added.
(foo):
* tests/stress/int52-variable.js: Added.
(foo):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@167455 268f45cc-cd09-0410-ab3c-d52691b4dbfc
FTL::fail() should manage memory "correctly"
https://bugs.webkit.org/show_bug.cgi?id=131823
<rdar://problem/16384297>

Reviewed by Oliver Hunt.

* ftl/FTLFail.cpp:
(JSC::FTL::fail):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@167456 268f45cc-cd09-0410-ab3c-d52691b4dbfc
_webProcessIdentifier should return 0 if the web process crashed
https://bugs.webkit.org/show_bug.cgi?id=131813
<rdar://problem/16650605>

Reviewed by Anders Carlsson.

* UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView _hasWebProcess]):
* UIProcess/API/Cocoa/WKWebViewPrivate.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@167457 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Hit-testing is incorrect for plugins inside iframes when there is a 
topContentInset
https://bugs.webkit.org/show_bug.cgi?id=131826
-and corresponding-
<rdar://problem/16649996>

Reviewed by Tim Horton.

I missed one coordinate-conversion spot when getting hit-testing to work. Like 
headerHeight() which also manipulates the location of the root layer, 
topContentInset() has to be factored into all of these conversions.
* page/FrameView.cpp:
(WebCore::FrameView::convertFromRenderer):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@167460 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[New Multicolumn] Column rules don't respect the specified stacking order.
https://bugs.webkit.org/show_bug.cgi?id=131804

Reviewed by Beth Dakin.


Source/WebCore: 
Added fast/multicol/newmulticol/compare_with_old_impl/column-rules-stacking.html

* rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::paintBoxDecorations):
* rendering/RenderBlockFlow.h:
Override paintBoxDecorations for block flows so that we can iterate over our column sets
and paint their rules just after painting our background and border. We can't wait until
the child column sets paint their backgrounds, since that is specified as being above negative
z-index children. We have to pretend that the column sets don't exist as
far as column rule painting is concerned.

* rendering/RenderMultiColumnSet.cpp:
(WebCore::RenderMultiColumnSet::paintObject): Deleted.
* rendering/RenderMultiColumnSet.h:
Turn paintObject in RenderMultiColumnSet into an override that doesn't paint anything.

LayoutTests: 
* fast/multicol/newmulticol/compare-with-old-impl/column-rules-stacking-expected.html: Added.
* fast/multicol/newmulticol/compare-with-old-impl/column-rules-stacking.html: Added.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@167463 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Cheesy Mountain Lion build fix.

* platform/MemoryPressureHandler.h:
(WebCore::MemoryPressureHandler::ReliefLogger::logString):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@167464 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[iOS] REGRESSION (r166975): WKPDFView is broken
https://bugs.webkit.org/show_bug.cgi?id=131828

Reviewed by Simon Fraser.

* UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView _didCommitLayerTree:WebKit::]):
Bail from updating the scroll view parameters from the layer tree update
while it's being managed by a custom content view.
We'll get any changes again in the next commit after removing the custom
content view (and painting the new page) anyway, so this should be OK.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@167465 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Rollout: Add a way to cache never-changing IDL attributes in the wrapper.
<https://webkit.org/b/131759>

This behavior may be observable from the web, so we can't do it this way.

* bindings/scripts/CodeGeneratorJS.pm:
(GenerateImplementation):
* bindings/scripts/IDLAttributes.txt:
* bindings/scripts/test/*:
* dom/Element.idl:
* dom/Node.idl:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@167466 268f45cc-cd09-0410-ab3c-d52691b4dbfc
InlineCallFrameSet should be refcounted
https://bugs.webkit.org/show_bug.cgi?id=131829

Reviewed by Geoffrey Garen.
        
And DFG::Plan should hold a ref to it. Previously it was owned by Graph until it
became owned by JITCode. Except that if we're "failing" to compile, JITCode may die.
Even as it dies, the GC may still want to scan the DFG::Plan, which leads to scanning
the DesiredWriteBarriers, which leads to scanning the InlineCallFrameSet.
        
So, just make the darn thing refcounted.

* bytecode/InlineCallFrameSet.h:
* dfg/DFGArgumentsSimplificationPhase.cpp:
(JSC::DFG::ArgumentsSimplificationPhase::run):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGCommonData.h:
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::Graph):
(JSC::DFG::Graph::requiredRegisterCountForExit):
* dfg/DFGGraph.h:
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::Plan):
* dfg/DFGPlan.h:
* dfg/DFGStackLayoutPhase.cpp:
(JSC::DFG::StackLayoutPhase::run):
* ftl/FTLFail.cpp:
(JSC::FTL::fail):
* ftl/FTLLink.cpp:
(JSC::FTL::link):



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