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
Patch (7.32 KB, patch)
2020-01-28 14:44 PST, Jonathan Bedard
no flags
Patch (17.20 KB, patch)
2020-01-29 08:27 PST, Jonathan Bedard
no flags
Patch (17.26 KB, patch)
2020-01-29 13:13 PST, Jonathan Bedard
no flags
Patch (18.83 KB, patch)
2020-01-30 09:47 PST, Jonathan Bedard
no flags
Patch (18.87 KB, patch)
2020-01-30 11:06 PST, Jonathan Bedard
no flags
Jonathan Bedard
Comment 1 2020-01-28 13:18:51 PST
Jonathan Bedard
Comment 2 2020-01-28 14:44:39 PST
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
Jonathan Bedard
Comment 7 2020-01-29 13:13:11 PST
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
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
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
Note You need to log in before you can comment on or make changes to this bug.