2014-09-02  Alex Christensen  <achristensen@webkit.org>

More use of WEBCORE_EXPORT.

Reviewed by Darin Adler.

These changes from a patch attached to https://bugs.webkit.org/show_bug.cgi?id=136172
contain more deployment of the WEBCORE_EXPORT macro. As of this writing, the macro is
defined to do nothing, so landing these is a harmless way to get closer to be the point
where we can throw the switch to use these instead of explicit export files on OS X,
iOS, and Windows.

* bindings/js/JSDOMBinding.h:
* bindings/js/JSDOMGlobalObject.h:
* bindings/js/JSDOMWindowBase.h:
* bindings/scripts/CodeGeneratorJS.pm:
(GenerateHeader):
(GenerateImplementation):
* bindings/scripts/CodeGeneratorObjC.pm:
(GenerateHeader):
* bridge/runtime_method.cpp:
* bridge/runtime_object.cpp:
* dom/Document.h:
* dom/Element.h:
* dom/Position.h:
* dom/Range.h:
* dom/StaticNodeList.h:
* dom/make_names.pl:
(printInit):
(printNamesCppFile):
* editing/Editor.h:
* editing/FrameSelection.h:
* editing/TextIterator.h:
* inspector/InspectorFrontendClient.h:
* inspector/InspectorFrontendClientLocal.h:
* loader/DocumentLoader.h:
* loader/FrameLoader.h:
* loader/cache/MemoryCache.h:
* loader/cocoa/DiskCacheMonitorCocoa.h:
* loader/mac/LoaderNSURLExtras.h:
* page/Page.h:
* page/PageGroup.h:
* page/SecurityPolicy.h:
* page/Settings.h:
* page/make_settings.pl:
(printGetterAndSetter):
* page/scrolling/ScrollingStateScrollingNode.h:
* platform/CrossThreadCopier.h:
* platform/LocalizedStrings.h:
* platform/MemoryPressureHandler.cpp:
* platform/PlatformScreen.h:
* platform/PublicSuffix.h:
* platform/graphics/Gradient.h:
* platform/graphics/cocoa/WebActionDisablingCALayerDelegate.h:
* platform/graphics/filters/FilterOperation.h:
* platform/ios/WebVideoFullscreenControllerAVKit.h:
* platform/mac/PlatformEventFactoryMac.h:
* platform/mac/WebCoreFullScreenPlaceholderView.h:
* platform/mac/WebCoreFullScreenWindow.h:
* platform/mac/WebCoreNSStringExtras.h:
* platform/mac/WebCoreObjCExtras.h:
* platform/mac/WebFontCache.h:
* platform/mac/WebVideoFullscreenController.h:
* platform/mac/WebWindowAnimation.h:
* platform/network/BlobRegistryImpl.h:
* platform/network/CredentialStorage.h:
* platform/network/PlatformCookieJar.h:
* platform/network/ProxyServer.h:
* platform/sql/SQLiteStatement.h:
* platform/text/TextEncoding.h:
* rendering/HitTestResult.h:
* rendering/RenderTreeAsText.h:
* testing/Internals.h:
Add many more correct uses of WEBCORE_EXPORT; remove a few incorrect ones.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@173176 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed, rolling out r173175.
https://bugs.webkit.org/show_bug.cgi?id=136454

it broke debug builds (Requested by jessieberlin on #webkit).

Reverted changeset:

"Introduce CSS_BASIC_TYPE_CASTS, and use it"
https://bugs.webkit.org/show_bug.cgi?id=136403
http://trac.webkit.org/changeset/173175

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@173177 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Out of bounds write in vmEntryToJavaScript / JSC::JITCode::execute
https://bugs.webkit.org/show_bug.cgi?id=136305

Reviewed by Filip Pizlo.

Source/JavaScriptCore:

While preparing the callee's CallFrame, ProtoCallFrame fixes any arity mismatch
and then JITCode::execute() calls the normal entrypoint.  This is incompatible
with the expectation of FTL generated functions.  Changed ProtoCallFrame to not 
perform the arity fix, but just flag an arity mismatch.  now JITCode::execute()
uses that arity mismatch condition to select the normal or arity check
entrypoint.  The entrypoint selection is only done for functions, programs
and eval always have one parameter.

* interpreter/ProtoCallFrame.cpp:
(JSC::ProtoCallFrame::init): Changed to flag arity mismatch instead of fixing it.
* interpreter/ProtoCallFrame.h:
(JSC::ProtoCallFrame::needArityCheck): New boolean to signify what entrypoint
should be called.
* jit/JITCode.cpp:
(JSC::JITCode::execute): Select normal or arity check entrypoint as appropriate.

LayoutTests:

* js/arity-mismatch-at-vmentry-expected.txt: Added.
* js/arity-mismatch-at-vmentry.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@173178 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[ARM] MacroAssembler generating incorrect code on ARM32 Traditional
https://bugs.webkit.org/show_bug.cgi?id=136429

Reviewed by Csaba Osztrogonác.

Changed test32 to use tst to check if reg is zero, instead of cmp.

* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::test32):


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