Bug 195255 – Remove some more unused 32-bit code

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Tim Horton]

Remove some more unused 32-bit code

[Tim Horton]

Created attachment 363447 [details]
Patch

[Tim Horton]

Comment on attachment 363447 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=363447&action=review

> Source/WebCore/page/CaptionUserPreferencesMediaAF.cpp:-472
> -#if defined(__LP64__) && __LP64__

I think this one needs to stay, if this code is built for Windows.

[Darin Adler]

Comment on attachment 363447 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=363447&action=review

Seems super-unlikely it’s caused by this patch, but clearly the "using namespace WebCore" needs to be removed from Source/WebKit/Shared/Plugins/unix/PluginSearchPath.cpp, the file doesn’t use anything form WebCore.

>> Source/WebCore/page/CaptionUserPreferencesMediaAF.cpp:-472
>> -#if defined(__LP64__) && __LP64__
> 
> I think this one needs to stay, if this code is built for Windows.

Looks like the file is included in the Windows build, not sure about this particular line of code.

> Source/WebCore/platform/graphics/cocoa/FontCascadeCocoa.mm:-54
> -#ifdef __LP64__
>  #define URefCon void*
> -#else
> -#define URefCon UInt32
> -#endif

There’s no use of URefCon so we can just delete this all.

> Source/WebKit/Shared/mac/WebEventFactory.mm:360
>      double force = 0;

Should just define this below where it’s initialized.

[EWS Watchlist]

Comment on attachment 363447 [details]
Patch

Attachment 363447 [details] did not pass mac-ews (mac):
Output: https://webkit-queues.webkit.org/results/11349776

New failing tests:
platform/mac/plugins/supports-carbon-event-model.html

[EWS Watchlist]

Created attachment 363450 [details]
Archive of layout-test-results from ews103 for mac-highsierra

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews103  Port: mac-highsierra  Platform: Mac OS X 10.13.6

[EWS Watchlist]

Comment on attachment 363447 [details]
Patch

Attachment 363447 [details] did not pass mac-wk2-ews (mac-wk2):
Output: https://webkit-queues.webkit.org/results/11349843

New failing tests:
platform/mac/plugins/supports-carbon-event-model.html

[EWS Watchlist]

Created attachment 363451 [details]
Archive of layout-test-results from ews107 for mac-highsierra-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews107  Port: mac-highsierra-wk2  Platform: Mac OS X 10.13.6

[Tim Horton]

Created attachment 363452 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 363452 [details]
Patch

Clearing flags on attachment: 363452

Committed r242325: <https://trac.webkit.org/changeset/242325>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/48542991>

Comment on attachment 363452 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=363452&action=review

> Source/WebKit/Shared/API/Cocoa/WKFoundation.h:30
>  #define WK_API_ENABLED 1

Is this useful anymore?

[Darin Adler]

Comment on attachment 363452 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=363452&action=review

>> Source/WebKit/Shared/API/Cocoa/WKFoundation.h:30
>>  #define WK_API_ENABLED 1
> 
> Is this useful anymore?

I guess what you are asking is: Is it useful to be able to set WK_API_ENABLED to 0? If not, we can remove the 700+ references to it!

[Tim Horton]

No, it's not, but the patch was getting out of hand so I wanted to do that one separately :)

[Tim Horton]

(In reply to Tim Horton from comment #14)
> No, it's not, but the patch was getting out of hand so I wanted to do that
> one separately :)

... which was a good call, since the WK_API_ENABLED patch is 4x the size of this one: https://bugs.webkit.org/show_bug.cgi?id=195263