Bug 188955 - [Cocoa] Adapt more WebKit code to be ARC-compatible
Summary: [Cocoa] Adapt more WebKit code to be ARC-compatible
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Darin Adler
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-08-26 14:14 PDT by Darin Adler
Modified: 2021-03-17 12:03 PDT (History)
6 users (show)

See Also:


Attachments
Patch (77.63 KB, patch)
2018-08-26 14:42 PDT, Darin Adler
no flags Details | Formatted Diff | Diff
Patch (79.13 KB, patch)
2018-08-26 15:11 PDT, Darin Adler
andersca: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Darin Adler 2018-08-26 14:14:52 PDT
[Cocoa] Adapt more WebKit code to be ARC-compatible
Comment 1 Darin Adler 2018-08-26 14:42:58 PDT Comment hidden (obsolete)
Comment 2 EWS Watchlist 2018-08-26 14:44:52 PDT Comment hidden (obsolete)
Comment 3 Darin Adler 2018-08-26 15:11:34 PDT
Created attachment 348104 [details]
Patch
Comment 4 EWS Watchlist 2018-08-26 15:13:59 PDT
Attachment 348104 [details] did not pass style-queue:


ERROR: Source/WebKit/UIProcess/WebPageProxy.cpp:7329:  Declaration has space between type name and * in NSObject *WebPageProxy  [whitespace/declaration] [3]
Total errors found: 1 in 40 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 5 Darin Adler 2018-08-26 18:05:38 PDT
Looks like it’s compiling and passing tests everywhere.
Comment 6 Anders Carlsson 2018-08-27 07:04:25 PDT
Comment on attachment 348104 [details]
Patch

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

> Source/WebKit/Shared/API/c/cf/WKStringCF.mm:55
> +        CFRetain(cfString);
> +        return toAPI(static_cast<API::String*>(&[(WKNSString *)(__bridge NSString *)cfString _apiObject]));

I'd put the CFRetain inside the toAPI call instead of on a separate line.

> Source/WebKit/Shared/API/c/cf/WKURLCF.mm:58
> +        CFRetain(cfURL);

Same here.

> Source/WebKit/UIProcess/Cocoa/WebViewImpl.mm:2054
> -    [[event retain] autorelease];
> +    CFRetain((__bridge CFTypeRef)event);
> +    CFAutorelease((__bridge CFTypeRef)event);

I seem to remember that you can do something like

__autoreleasing NSEvent *autoreleasedEvent = event;

(I think we've done something similar in Safari).

> Source/WebKit/UIProcess/Cocoa/WebViewImpl.mm:2074
> -    [[event retain] autorelease];
> +    CFRetain((__bridge CFTypeRef)event);
> +    CFAutorelease((__bridge CFTypeRef)event);

Same thing here.
Comment 7 Darin Adler 2018-08-27 08:47:11 PDT
Comment on attachment 348104 [details]
Patch

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

>> Source/WebKit/Shared/API/c/cf/WKStringCF.mm:55
>> +        return toAPI(static_cast<API::String*>(&[(WKNSString *)(__bridge NSString *)cfString _apiObject]));
> 
> I'd put the CFRetain inside the toAPI call instead of on a separate line.

Done.

The reason I didn’t do that originally is that I wanted a construction where the __bridge cast will warn if we use the wrong toll-free bridged type and I was worried that CFRetain would cause the expression to dumb down its type from CFStringRef to CFTypeRef. But frankly I have no idea if it will do that or not, and I also guess the warning is not so important that I should work so hard to preserve it.

>> Source/WebKit/Shared/API/c/cf/WKURLCF.mm:58
>> +        CFRetain(cfURL);
> 
> Same here.

Done.

>> Source/WebKit/UIProcess/Cocoa/WebViewImpl.mm:2054
>> +    CFAutorelease((__bridge CFTypeRef)event);
> 
> I seem to remember that you can do something like
> 
> __autoreleasing NSEvent *autoreleasedEvent = event;
> 
> (I think we've done something similar in Safari).

I like the idea of moving to a better idiom. The thing I recall in Safari is a macro:

    #define AUTORELEASING_PROTECT(object) ({ __autoreleasing volatile id protector = object; (void)protector; })

I am not sure that’s better than explicit calls to CFRetain and CFAutorelease.

I’d be happy to switch idioms to something we like better: It will be easy to find all the call sites by searching for CFAutorelease; so far there are only 4, these 3 in WebKit and 1 I already landed in WebCore. For now I’d prefer to land these as just CFRetain/CFAutorelease since I’m not sure I prefer an idiom involving volatile and unused local variables.
Comment 8 Darin Adler 2018-08-27 08:51:30 PDT
Committed r235365: <https://trac.webkit.org/changeset/235365>
Comment 9 Radar WebKit Bug Importer 2018-08-27 08:52:24 PDT
<rdar://problem/43755547>