Bug 195255

Summary: Remove some more unused 32-bit code
Product: WebKit Reporter: Tim Horton <thorton>
Component: New BugsAssignee: Tim Horton <thorton>
Status: RESOLVED FIXED    
Severity: Normal CC: andersca, ap, commit-queue, darin, ews-watchlist, mitz, rniwa, simon.fraser, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Archive of layout-test-results from ews103 for mac-highsierra
none
Archive of layout-test-results from ews107 for mac-highsierra-wk2
none
Patch none

Description Tim Horton 2019-03-02 22:58:42 PST
Remove some more unused 32-bit code
Comment 1 Tim Horton 2019-03-02 22:59:04 PST Comment hidden (obsolete)
Comment 2 Tim Horton 2019-03-02 23:00:57 PST
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.
Comment 3 Darin Adler 2019-03-02 23:45:17 PST
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.
Comment 4 EWS Watchlist 2019-03-03 00:03:13 PST Comment hidden (obsolete)
Comment 5 EWS Watchlist 2019-03-03 00:03:15 PST Comment hidden (obsolete)
Comment 6 EWS Watchlist 2019-03-03 00:15:31 PST Comment hidden (obsolete)
Comment 7 EWS Watchlist 2019-03-03 00:15:32 PST Comment hidden (obsolete)
Comment 8 Tim Horton 2019-03-03 00:35:04 PST
Created attachment 363452 [details]
Patch
Comment 9 WebKit Commit Bot 2019-03-03 02:35:53 PST
Comment on attachment 363452 [details]
Patch

Clearing flags on attachment: 363452

Committed r242325: <https://trac.webkit.org/changeset/242325>
Comment 10 WebKit Commit Bot 2019-03-03 02:35:55 PST
All reviewed patches have been landed.  Closing bug.
Comment 11 Radar WebKit Bug Importer 2019-03-03 02:50:49 PST
<rdar://problem/48542991>
Comment 12 mitz 2019-03-03 07:52:21 PST
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?
Comment 13 Darin Adler 2019-03-03 12:12:40 PST
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!
Comment 14 Tim Horton 2019-03-03 12:16:55 PST
No, it's not, but the patch was getting out of hand so I wanted to do that one separately :)
Comment 15 Tim Horton 2019-03-03 20:16:04 PST
(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