[Cocoa] Turn on ARC for WebKitTestRunner
Created attachment 348729 [details] Patch
Created attachment 348746 [details] Patch
Created attachment 348777 [details] Patch
Comment on attachment 348777 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=348777&action=review > Tools/WebKitTestRunner/InjectedBundle/ios/AccessibilityTextMarkerIOS.mm:32 > + return [(__bridge id)platformTextMarker() isEqual:(__bridge id)other->platformTextMarker()]; Is there any way to make platformTextMarker() return (or rather make PlatformTextMarker) an id rather than CFTypeRef? I know in WebCore we use the trick of doing something like: #ifndef __OBJC__ typedef struct objc_object *id; #endif in the C++ class. Though I am not sure what the implications for ARC are of that. > Tools/WebKitTestRunner/InjectedBundle/ios/AccessibilityUIElementIOS.mm:1066 > + return AccessibilityTextMarkerRange::create((__bridge PlatformTextMarkerRange)textMarkerRange); Same question as above, but for PlatformTextMarkerRange. > Tools/WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm:1825 > - id mutableString = [[[NSMutableString alloc] init] autorelease]; > + id mutableString = [[NSMutableString alloc] init]; Seems like this could be NSMutableString * rather than id (as long as you are changing this line). > Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm:138 > + return JSStringCreateWithCFString((__bridge CFStringRef)webView.accessibilitySpeakSelectionContent); There is a category in WebKitTestRunner that adds a -[NSString createJSStringRef] (and a +[NSString stringWithJSStringRef:]). It is currently in AccessibilityCommonMac.h, but seems more generally useful (could probably add ones for WKStringRef as well if we were going wild).
Committed r235832: <https://trac.webkit.org/changeset/235832>
<rdar://problem/44264628>
This patch broke WebKit2 tests, because it apparently makes system resources leak. Rolling back. EWS detected this before landing. worker/10: OSError('[Errno 35] Resource temporarily unavailable') raised: File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/common/message_pool.py", line 257, in run worker.handle(message.name, message.src, *message.args) File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/layout_tests/controllers/layout_test_runner.py", line 283, in handle ...
Re-opened since this is blocked by bug 189464
This did not break WebKit2 tests on my computer.
(In reply to Alexey Proskuryakov from comment #7) > This patch broke WebKit2 tests, because it apparently makes system resources > leak. Rolling back. > > EWS detected this before landing. > > > worker/10: OSError('[Errno 35] Resource temporarily unavailable') raised: > File > "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/common/message_pool.py", > line 257, in run > worker.handle(message.name, message.src, *message.args) > File > "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/layout_tests/controllers/ > layout_test_runner.py", line 283, in handle > ... I’m accustomed to seeing this on EWS when there is a server problem, which is why I didn’t realize it was a problem with the patch. I guess I can abandon this for now because I’m not sure what to do next since I don’t see any problem locally.
Watching open files and processes with lsof and ps would likely be the most straightforward way to see what's going on locally. It's also possible that this is something specific to Sierra and the version of clang used there. This doesn't feel like a very likely cause to me though.
Thanks. I will try your suggestion next time I have an opportunity to work on this.