WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
136280
Use RetainPtr::autorelease in some places where it seems appropriate
https://bugs.webkit.org/show_bug.cgi?id=136280
Summary
Use RetainPtr::autorelease in some places where it seems appropriate
Maciej Stachowiak
Reported
2014-08-26 21:46:19 PDT
Use RetainPtr::autorelease in some places where it seems appropriate
Attachments
Patch
(9.03 KB, patch)
2014-08-26 21:49 PDT
,
Maciej Stachowiak
no flags
Details
Formatted Diff
Diff
Version that actually compiles
(9.53 KB, patch)
2014-08-27 00:32 PDT
,
Maciej Stachowiak
darin
: review+
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Maciej Stachowiak
Comment 1
2014-08-26 21:49:59 PDT
Created
attachment 237201
[details]
Patch
Maciej Stachowiak
Comment 2
2014-08-27 00:32:32 PDT
Created
attachment 237213
[details]
Version that actually compiles
Darin Adler
Comment 3
2014-08-27 11:47:04 PDT
Comment on
attachment 237213
[details]
Version that actually compiles View in context:
https://bugs.webkit.org/attachment.cgi?id=237213&action=review
> Source/JavaScriptCore/API/JSContext.mm:195 > + return (NSString *)adoptCF(JSStringCopyCFString(kCFAllocatorDefault, name)).autorelease();
Seeing all these type casts makes it seem to me that the return type from autorelease() is not quite right. It’s perfect for functions that return autoreleased CF objects, which is almost never an idiom. It’s not great for functions that return autoreleased NS objects due to toll free bridging, which is what will really happen. I’d like to see a function like autorelease that only works for types that have toll free bridging and automatically returns the right type, so we can omit all these casts and have type checking. Or one that returns (id). We might still want one that returns the unmolested CF type, but I’m not sure we ever really need that in practice. Maybe we can turn autorelease into that. One further note. The current autorelease() implementation, if ever used under ARC, would only be good if the result was going into an NS type. If we ever actually tried to use it with the CF type I suspect it would do the wrong thing and not actually autorelease. Yet another argument for changing the return type of the function to an NS type.
Maciej Stachowiak
Comment 4
2014-08-27 18:04:41 PDT
(In reply to
comment #3
)
> (From update of
attachment 237213
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=237213&action=review
> > > Source/JavaScriptCore/API/JSContext.mm:195 > > + return (NSString *)adoptCF(JSStringCopyCFString(kCFAllocatorDefault, name)).autorelease(); > > Seeing all these type casts makes it seem to me that the return type from autorelease() is not quite right. It’s perfect for functions that return autoreleased CF objects, which is almost never an idiom. It’s not great for functions that return autoreleased NS objects due to toll free bridging, which is what will really happen. > > I’d like to see a function like autorelease that only works for types that have toll free bridging and automatically returns the right type, so we can omit all these casts and have type checking. Or one that returns (id). We might still want one that returns the unmolested CF type, but I’m not sure we ever really need that in practice. Maybe we can turn autorelease into that. > > One further note. The current autorelease() implementation, if ever used under ARC, would only be good if the result was going into an NS type. If we ever actually tried to use it with the CF type I suspect it would do the wrong thing and not actually autorelease. Yet another argument for changing the return type of the function to an NS type.
Do we have a generic way to map a CF type to its corresponding NS type?
Darin Adler
Comment 5
2014-08-28 09:38:59 PDT
Comment on
attachment 237213
[details]
Version that actually compiles View in context:
https://bugs.webkit.org/attachment.cgi?id=237213&action=review
>>> Source/JavaScriptCore/API/JSContext.mm:195 >>> + return (NSString *)adoptCF(JSStringCopyCFString(kCFAllocatorDefault, name)).autorelease(); >> >> Seeing all these type casts makes it seem to me that the return type from autorelease() is not quite right. It’s perfect for functions that return autoreleased CF objects, which is almost never an idiom. It’s not great for functions that return autoreleased NS objects due to toll free bridging, which is what will really happen. >> >> I’d like to see a function like autorelease that only works for types that have toll free bridging and automatically returns the right type, so we can omit all these casts and have type checking. Or one that returns (id). We might still want one that returns the unmolested CF type, but I’m not sure we ever really need that in practice. Maybe we can turn autorelease into that. >> >> One further note. The current autorelease() implementation, if ever used under ARC, would only be good if the result was going into an NS type. If we ever actually tried to use it with the CF type I suspect it would do the wrong thing and not actually autorelease. Yet another argument for changing the return type of the function to an NS type. > > Do we have a generic way to map a CF type to its corresponding NS type?
Anders prototyped something called TollFreeBridging.h but he has not yet proposed adding it to WebKit.
Maciej Stachowiak
Comment 6
2014-08-30 15:44:23 PDT
Committed
r173141
: <
http://trac.webkit.org/changeset/173141
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug