WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
206905
PAL: Remove old iOS version macros
https://bugs.webkit.org/show_bug.cgi?id=206905
Summary
PAL: Remove old iOS version macros
Jonathan Bedard
Reported
2020-01-28 13:11:31 PST
There are a number of platform differentiation macros that are implemented as version checks in PAL, these should be reimplemented as platform checks.
Attachments
Patch
(7.31 KB, patch)
2020-01-28 13:18 PST
,
Jonathan Bedard
no flags
Details
Formatted Diff
Diff
Patch
(7.32 KB, patch)
2020-01-28 14:44 PST
,
Jonathan Bedard
no flags
Details
Formatted Diff
Diff
Patch
(17.20 KB, patch)
2020-01-29 08:27 PST
,
Jonathan Bedard
no flags
Details
Formatted Diff
Diff
Patch
(17.26 KB, patch)
2020-01-29 13:13 PST
,
Jonathan Bedard
no flags
Details
Formatted Diff
Diff
Patch
(18.83 KB, patch)
2020-01-30 09:47 PST
,
Jonathan Bedard
no flags
Details
Formatted Diff
Diff
Patch
(18.87 KB, patch)
2020-01-30 11:06 PST
,
Jonathan Bedard
no flags
Details
Formatted Diff
Diff
Show Obsolete
(5)
View All
Add attachment
proposed patch, testcase, etc.
Jonathan Bedard
Comment 1
2020-01-28 13:18:51 PST
Created
attachment 389055
[details]
Patch
Jonathan Bedard
Comment 2
2020-01-28 14:44:39 PST
Created
attachment 389067
[details]
Patch
Darin Adler
Comment 3
2020-01-28 16:46:44 PST
Comment on
attachment 389067
[details]
Patch What made you choose "USE" over "HAVE" here? Typically in situations like this we want to use it wherever we have it. So I would think these would be HAVE. We reserve USE for where the decision to use is a more complex question than just "use what you have".
Darin Adler
Comment 4
2020-01-28 16:47:07 PST
Comment on
attachment 389067
[details]
Patch I guess the things in-file said USE, but I think they are wrong.
Jonathan Bedard
Comment 5
2020-01-29 08:03:19 PST
(In reply to Darin Adler from
comment #4
)
> Comment on
attachment 389067
[details]
> Patch > > I guess the things in-file said USE, but I think they are wrong.
That's exactly why I implemented them as USE. I'll change them to HAVE
Jonathan Bedard
Comment 6
2020-01-29 08:27:09 PST
Created
attachment 389140
[details]
Patch
Jonathan Bedard
Comment 7
2020-01-29 13:13:11 PST
Created
attachment 389175
[details]
Patch
Darin Adler
Comment 8
2020-01-30 09:00:19 PST
Comment on
attachment 389175
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=389175&action=review
> Source/WTF/wtf/PlatformHave.h:580 > +#if PLATFORM(COCOA) > +#define HAVE_SECURE_ARCHIVER_API 1 > +#endif
Since this is used only in Cocoa-specific source files, we can remove the conditional entirely and enable things unconditionally. This avoids having to move it into PlatformHave.h.
> Source/WTF/wtf/PlatformHave.h:584 > +#if PLATFORM(MAC) || PLATFORM(IOS_FAMILY) > +#define HAVE_SECURE_ARCHIVER_FOR_ATTRIBUTED_STRING 1 > +#endif
This expression is the same as PLATFORM(COCOA). Since this is used only in Cocoa-specific source files, we can remove the conditional entirely and enable things unconditionally. This avoids having to move it into PlatformHave.h.
> Source/WTF/wtf/PlatformHave.h:588 > +#if PLATFORM(WATCHOS) || PLATFORM(APPLETV) || (PLATFORM(IOS_FAMILY) && !(defined __has_include && __has_include(<CoreFoundation/CFPriv.h>))) > +#define HAVE_NSPROGRESS_PUBLISHING_SPI 1 > +#endif
I don’t understand why we are adding __has_include here. The old code didn’t use it. I believe we should use that only when absolutely necessary and I don’t see a comment explaining why it’s necessary here. I think this should just be PLATFORM(IOS_FAMILY).
> Source/WebCore/PAL/pal/spi/cg/CoreGraphicsSPI.h:287 > +#if HAVE(CG_PATH_UNEVEN_CORNERS_ROUNDEDRECT) > void CGPathAddUnevenCornersRoundedRect(CGMutablePathRef, const CGAffineTransform *, CGRect, const CGSize corners[4]); > #endif
Seems to me it might be OK to just have this unconditionally in the SPI header, as long as the actual use of the function is guarded by HAVE(CG_PATH_UNEVEN_CORNERS_ROUNDEDRECT). But I guess this way is OK too.
Jonathan Bedard
Comment 9
2020-01-30 09:20:26 PST
Comment on
attachment 389175
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=389175&action=review
>> Source/WTF/wtf/PlatformHave.h:588 >> +#endif > > I don’t understand why we are adding __has_include here. The old code didn’t use it. I believe we should use that only when absolutely necessary and I don’t see a comment explaining why it’s necessary here. > > I think this should just be PLATFORM(IOS_FAMILY).
Because this is actually: #if PLATFORM(WATCHOS) || PLATFORM(APPLETV) || (PLATFORM(IOS_FAMILY) && !USE(APPLE_INTERNAL_SDK)) but we don't have USE macros in the HAVE macro file. It might be better to just move this back into the file that originally contains it.
Jonathan Bedard
Comment 10
2020-01-30 09:47:05 PST
Created
attachment 389259
[details]
Patch
Darin Adler
Comment 11
2020-01-30 10:19:48 PST
Comment on
attachment 389175
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=389175&action=review
>>> Source/WTF/wtf/PlatformHave.h:588 >>> +#endif >> >> I don’t understand why we are adding __has_include here. The old code didn’t use it. I believe we should use that only when absolutely necessary and I don’t see a comment explaining why it’s necessary here. >> >> I think this should just be PLATFORM(IOS_FAMILY). > > Because this is actually: > > #if PLATFORM(WATCHOS) || PLATFORM(APPLETV) || (PLATFORM(IOS_FAMILY) && !USE(APPLE_INTERNAL_SDK)) > > but we don't have USE macros in the HAVE macro file. It might be better to just move this back into the file that originally contains it.
Yes should go to USE because we for some reason are only compiling this for people who have the internal SDK. But not a good situation. Not a normal part of how we want to do things. An anomaly that we should eventually fix. Our SPI headers are designed to allow us to avoid this situation.
Darin Adler
Comment 12
2020-01-30 10:32:42 PST
Comment on
attachment 389259
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=389259&action=review
> Source/WTF/wtf/PlatformHave.h:578 > +#if PLATFORM(WATCHOS) || PLATFORM(APPLETV) || (PLATFORM(IOS_FAMILY) && !(defined __has_include && __has_include(<CoreFoundation/CFPriv.h>)))
Still not happy with this but maybe we can land it like this and improve later. I’m concerned we don’t understand this well enough. It seems that this is about using SPI vs. API and I am it sure it’s right.
> Source/WebCore/PAL/pal/spi/cocoa/NSKeyedArchiverSPI.h:55 > inline NSData *_Nullable securelyArchivedDataWithRootObject(id _Nonnull object)
Should probably come back here and remove this from the SPI header. This is here only to keep the conditionals out of the source dukes and that is no longer a concern.
> Source/WebCore/PAL/pal/spi/cocoa/NSKeyedArchiverSPI.h:64 > inline NSData *_Nullable insecurelyArchivedDataWithRootObject(id _Nonnull object)
Ditto.
> Source/WebCore/PAL/pal/spi/cocoa/NSKeyedArchiverSPI.h:80 > inline id _Nullable unarchivedObjectOfClassesFromData(NSSet<Class> * _Nonnull classes, NSData * _Nonnull data)
Ditto.
> Source/WebCore/PAL/pal/spi/cocoa/NSKeyedArchiverSPI.h:89 > inline RetainPtr<NSKeyedArchiver> secureArchiver()
Ditto.
> Source/WebCore/PAL/pal/spi/cocoa/NSKeyedArchiverSPI.h:95 > inline RetainPtr<NSKeyedUnarchiver> secureUnarchiverFromData(NSData *_Nonnull data)
Ditto.
> Source/WebCore/PAL/pal/spi/cocoa/NSKeyedArchiverSPI.h:102 > inline id _Nullable decodeObjectOfClassForKeyFromCoder(Class _Nonnull cls, NSString * _Nonnull key, NSCoder * _Nonnull coder)
Ditto.
> Source/WebCore/loader/archive/cf/LegacyWebArchiveMac.mm:68 > return retainPtr((__bridge CFDataRef)archiver.get().encodedData);
Just something I noticed in passing: no need to call retainPtr here.
Jonathan Bedard
Comment 13
2020-01-30 11:03:30 PST
Comment on
attachment 389259
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=389259&action=review
>> Source/WTF/wtf/PlatformHave.h:578 >> +#if PLATFORM(WATCHOS) || PLATFORM(APPLETV) || (PLATFORM(IOS_FAMILY) && !(defined __has_include && __has_include(<CoreFoundation/CFPriv.h>))) > > Still not happy with this but maybe we can land it like this and improve later. I’m concerned we don’t understand this well enough. It seems that this is about using SPI vs. API and I am it sure it’s right.
Looking through our callsites, I suspect we no longer need the Internal check, but I'll file a different bug about that,
https://bugs.webkit.org/show_bug.cgi?id=207008
>> Source/WebCore/PAL/pal/spi/cocoa/NSKeyedArchiverSPI.h:55 >> inline NSData *_Nullable securelyArchivedDataWithRootObject(id _Nonnull object) > > Should probably come back here and remove this from the SPI header. This is here only to keep the conditionals out of the source dukes and that is no longer a concern.
Filed
https://bugs.webkit.org/show_bug.cgi?id=207009
>> Source/WebCore/loader/archive/cf/LegacyWebArchiveMac.mm:68 >> return retainPtr((__bridge CFDataRef)archiver.get().encodedData); > > Just something I noticed in passing: no need to call retainPtr here.
Updating the patch to fix this one.
Jonathan Bedard
Comment 14
2020-01-30 11:06:28 PST
Created
attachment 389269
[details]
Patch
WebKit Commit Bot
Comment 15
2020-01-30 13:36:42 PST
Comment on
attachment 389269
[details]
Patch Clearing flags on attachment: 389269 Committed
r255455
: <
https://trac.webkit.org/changeset/255455
>
WebKit Commit Bot
Comment 16
2020-01-30 13:36:44 PST
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 17
2020-01-30 13:37:22 PST
<
rdar://problem/59039984
>
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