199705 2019-07-11 03:50:02 -0700 Build failure in WebHTMLView.mm with the public SDK (Xcode 11 and Mojave) 2019-10-07 18:03:19 -0700 1 1 1 Unclassified WebKit WebKit Misc. WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED InRadar P1 Major --- 199209 202263 1 fred.wang webkit-unassigned achristensen ajuma ap benjamin cathiechen cdumez cmarcelo commit-queue dbates dino ews-watchlist jbedard kbr mitz mjs rwlbuis thorton timothy webkit-bug-importer yurys oldest_to_newest 1552017 0 fred.wang 2019-07-11 03:50:02 -0700 Follow-up of https://bugs.webkit.org/show_bug.cgi?id=199279#c4 Using XCode 11.0 beta 3 and the public SDK, I get errors in the part of WebKitLegacy/mac/WebView/WebHTMLView.mm protected by SUBVIEWS_IVAR_SPI: use of undeclared identifier '_subviews' Not sure what is the proper API to use and why SUBVIEWS_IVAR_SPI is actually not enabled. (Removing any reference to _subviews make the build succeed, so that's the only remaining failure) 1552066 1 jbedard 2019-07-11 08:26:12 -0700 This is a bit surprising since I got a version building with the public SDK. Once I finish verifying getting the iOS 13 build working, I'll update my seed build and try and fix this. 1552097 2 ap 2019-07-11 10:14:48 -0700 Fred clarifies in the other bug that this is about Xcode 11.0 beta 3 on Mojave, not on Catalina. 1552115 3 jbedard 2019-07-11 10:57:30 -0700 (In reply to Alexey Proskuryakov from comment #2) > Fred clarifies in the other bug that this is about Xcode 11.0 beta 3 on > Mojave, not on Catalina. Ok, that makes more sense. HAVE_SUBVIEWS_IVAR_SPI only gets defined on Catalina. Should is be defined unconditionally on public SDKs? 1552123 4 timothy 2019-07-11 11:12:30 -0700 (In reply to Jonathan Bedard from comment #3) > (In reply to Alexey Proskuryakov from comment #2) > > Fred clarifies in the other bug that this is about Xcode 11.0 beta 3 on > > Mojave, not on Catalina. > > Ok, that makes more sense. HAVE_SUBVIEWS_IVAR_SPI only gets defined on > Catalina. Should is be defined unconditionally on public SDKs? The SPI only exists on Catalina. It would build but crash with a missing selector otherwise. I'll need to think of a fix that will work with the older systems and newer SDK. 1558464 5 jbedard 2019-08-05 09:51:57 -0700 Talked with Alexey a bit about this last week. None of our automation even builds with an old OS install and a new SDK, we're always either a new OS with a new SDK or an old OS with and old SDK. Because of this, I don't know that we have a compelling reason to fix this problem. 1558572 6 ap 2019-08-05 15:02:47 -0700 I think that this can't be just ignored, as contributors will certainly be installing a newer Xcode. The challenge is that even with this build fix, there could be other things that go wrong in less obvious ways. 1558579 7 jbedard 2019-08-05 15:21:20 -0700 (In reply to Alexey Proskuryakov from comment #6) > I think that this can't be just ignored, as contributors will certainly be > installing a newer Xcode. > > The challenge is that even with this build fix, there could be other things > that go wrong in less obvious ways. Without builder and testers, I don't know that we can practically expect to keep breakage like this out of the build. If we don't have any supporting automation, I don't know that we can claim this is a configuration we intend to support. 1566174 8 fred.wang 2019-08-29 03:28:23 -0700 Hi, I think it makes sense not to build/test/support a beta version of XCode together with a release operating system, if that's adding burden. From the user's point of view, it's a shame because it's harder to switch between building with two OS versions than between building with two XCode versions. In any case, if that configuration is really not supported, I think the build script should explicitly fail during configuration step with a clear error message. Incidentally, you mention that your automation builds a new OS with a new SDK but I can't find any public buildbot for Catalina/iOS13 on https://build.webkit.org/console ? Without that, how can external contributors find issues like bug 200000 comment 32 ? And to debug them, I guess they have to switch to newer Catalina / XCode ? 1574396 9 fred.wang 2019-09-26 02:36:25 -0700 This failure now happens with the Xcode 11 release on Mojave. 1574440 10 jbedard 2019-09-26 07:35:15 -0700 How does your setup compare with the iOS 13 bots? https://build.webkit.org/buildslaves/bot651 1574605 11 fred.wang 2019-09-26 13:25:18 -0700 (In reply to Jonathan Bedard from comment #10) > How does your setup compare with the iOS 13 bots? > > https://build.webkit.org/buildslaves/bot651 I still have the same build error after a clean rebuild. I have macOS 10.14.6 but only Xcode 11.0 11A420a (while buildbot is Xcode 11.1 Build version 11A1027). I noticed a new system update today, not sure that would actually help here but I'm downloading it now. 1574624 12 fred.wang 2019-09-26 14:13:44 -0700 (In reply to Frédéric Wang (:fredw) from comment #11) > I still have the same build error after a clean rebuild. I have macOS > 10.14.6 but only Xcode 11.0 11A420a (while buildbot is Xcode 11.1 Build > version 11A1027). I noticed a new system update today, not sure that would > actually help here but I'm downloading it now. System upgrade didn't help. I didn't get Xcode 11.1 from the standard software update so I guess I'll just install it from developer.apple.com 1575187 13 yurys 2019-09-29 17:47:05 -0700 (In reply to Frédéric Wang (:fredw) from comment #8) > In any case, if that configuration is really not supported, I think the > build script should explicitly fail during configuration step with a clear > error message. > +1 for this. XCode 11 is what is suggested by default for download from Apple's site at the moment and it's so frustrating that a clean build will fail on Mac OS X 10.14. I assume the workaround for those who want to develop on OS X 10.14 is to downgrade to XCode 10. 1575203 14 cathiechen 2019-09-30 00:55:07 -0700 I tried to clean build with Xcode 11.1 on Mac 10.14.6, it also has the same error. 1575263 15 yurys 2019-09-30 09:18:06 -0700 (In reply to cathiechen from comment #14) > I tried to clean build with Xcode 11.1 on Mac 10.14.6, it also has the same > error. If you just need to build WebKit on Mac OS X 10.14.6 you can download XCode 10.3 XCode page on developer.apple.com doesn't seem to have other versions of XCode except 11.1. This direct link still works though: https://developer.apple.com/services-account/download?path=/Developer_Tools/Xcode_10.3/Xcode_10.3.xip 1577214 16 mitz 2019-10-05 07:51:20 -0700 (In reply to Timothy Hatcher from comment #4) > (In reply to Jonathan Bedard from comment #3) > > (In reply to Alexey Proskuryakov from comment #2) > > > Fred clarifies in the other bug that this is about Xcode 11.0 beta 3 on > > > Mojave, not on Catalina. > > > > Ok, that makes more sense. HAVE_SUBVIEWS_IVAR_SPI only gets defined on > > Catalina. Should is be defined unconditionally on public SDKs? > > The SPI only exists on Catalina. It would build but crash with a missing > selector otherwise. > > I'll need to think of a fix that will work with the older systems and newer > SDK. You should be able to declare the ivar in a class extension in that case. 1577232 17 kbr 2019-10-05 21:33:18 -0700 Ran into this problem too after updating to Xcode 11 on 10.4.6 in order to pick up the iOS 13 SDK, which seemed required to build for the iOS Simulator. This presents a chicken-and-egg problem since it's not possible to build for the iOS Simulator without Xcode 11, but not possible to build for macOS with it. I was able to work around this by adding the following hack to WebHTMLView.mm: diff --git a/Source/WebKitLegacy/mac/WebView/WebHTMLView.mm b/Source/WebKitLegacy/mac/WebView/WebHTMLView.mm index 347826af20a..448d4c714d9 100644 --- a/Source/WebKitLegacy/mac/WebView/WebHTMLView.mm +++ b/Source/WebKitLegacy/mac/WebView/WebHTMLView.mm @@ -217,6 +217,8 @@ #if !HAVE(SUBVIEWS_IVAR_SPI) @implementation NSView (SubviewsIvar) +NSMutableArray<__kindof NSView *> *_subviews; + - (void)_setSubviewsIvar:(NSMutableArray<__kindof NSView *> *)subviews { ALLOW_DEPRECATED_DECLARATIONS_BEGIN _subviews = subviews; but am sure this isn't correct. I don't know enough Objective-C to postulate a correct fix. Any help from folks at Apple? May I please upgrade this to P1, Major issue? It is a serious problem for all contributors outside Apple. 1577233 18 mitz 2019-10-05 21:38:07 -0700 (In reply to Kenneth Russell from comment #17) > Ran into this problem too after updating to Xcode 11 on 10.4.6 in order to > pick up the iOS 13 SDK, which seemed required to build for the iOS > Simulator. This presents a chicken-and-egg problem since it's not possible > to build for the iOS Simulator without Xcode 11, but not possible to build > for macOS with it. > > I was able to work around this by adding the following hack to > WebHTMLView.mm: > > diff --git a/Source/WebKitLegacy/mac/WebView/WebHTMLView.mm > b/Source/WebKitLegacy/mac/WebView/WebHTMLView.mm > index 347826af20a..448d4c714d9 100644 > --- a/Source/WebKitLegacy/mac/WebView/WebHTMLView.mm > +++ b/Source/WebKitLegacy/mac/WebView/WebHTMLView.mm > @@ -217,6 +217,8 @@ > #if !HAVE(SUBVIEWS_IVAR_SPI) > @implementation NSView (SubviewsIvar) > > +NSMutableArray<__kindof NSView *> *_subviews; > + That’s not correct. It defines a global variable unrelated to the class. Declaring the ivar in a class extension, on the other hand, should work. 1577234 19 kbr 2019-10-05 21:42:41 -0700 (In reply to mitz from comment #18) > (In reply to Kenneth Russell from comment #17) > > Ran into this problem too after updating to Xcode 11 on 10.4.6 in order to > > pick up the iOS 13 SDK, which seemed required to build for the iOS > > Simulator. This presents a chicken-and-egg problem since it's not possible > > to build for the iOS Simulator without Xcode 11, but not possible to build > > for macOS with it. > > > > I was able to work around this by adding the following hack to > > WebHTMLView.mm: > > > > diff --git a/Source/WebKitLegacy/mac/WebView/WebHTMLView.mm > > b/Source/WebKitLegacy/mac/WebView/WebHTMLView.mm > > index 347826af20a..448d4c714d9 100644 > > --- a/Source/WebKitLegacy/mac/WebView/WebHTMLView.mm > > +++ b/Source/WebKitLegacy/mac/WebView/WebHTMLView.mm > > @@ -217,6 +217,8 @@ > > #if !HAVE(SUBVIEWS_IVAR_SPI) > > @implementation NSView (SubviewsIvar) > > > > +NSMutableArray<__kindof NSView *> *_subviews; > > + > > That’s not correct. It defines a global variable unrelated to the class. > Declaring the ivar in a class extension, on the other hand, should work. I know it's not correct. As I mentioned I don't know enough Objective-C to write a correct fix - any chance you could put up a patch implementing that? I'll be happy to help test it. Thanks. 1577235 20 380291 mitz 2019-10-05 21:50:07 -0700 Created attachment 380291 Untested patch > I know it's not correct. As I mentioned I don't know enough Objective-C to write a correct > fix - any chance you could put up a patch implementing that? I'll be happy to help test it. Thanks. I haven’t been able to test this patch, but this is what I had in mind. 1577268 21 mjs 2019-10-06 16:03:47 -0700 The wincairo and wk1 failures appear unrelated. The style checker issue is about having an OS version check here, correctly suggesting it should go in a named macro. I'd do this myself, but I'm not sure what the purpose of the `__MAC_OS_X_VERSION_MAX_ALLOWED >= 101500` clause is. For folks in this configuration who are having trouble building, could you please report whether the patch solves your problem? 1577269 22 mitz 2019-10-06 16:10:26 -0700 (In reply to Maciej Stachowiak from comment #21) > The wincairo and wk1 failures appear unrelated. > > The style checker issue is about having an OS version check here, correctly > suggesting it should go in a named macro. I'd do this myself, but I'm not > sure what the purpose of the `__MAC_OS_X_VERSION_MAX_ALLOWED >= 101500` > clause is. This makes the ivar declaration only when using the macOS Catalina or later SDK, because earlier SDKs include the declaration, and redeclaring an ivar is an error. I am not aware of WTF macros that express this (since conditionals based on SDK version are so uncommon). > For folks in this configuration who are having trouble building, could you > please report whether the patch solves your problem? 1577282 23 ap 2019-10-06 20:07:54 -0700 What style checker is saying is that we should add a HAVE macro for these SDKs in Platform.h. But looking at the patch, there is already HAVE(SUBVIEWS_IVAR_SPI). Isn’t it just defined improperly? 1577283 24 mitz 2019-10-06 20:11:27 -0700 (In reply to Alexey Proskuryakov from comment #23) > What style checker is saying is that we should add a HAVE macro for these > SDKs in Platform.h. But looking at the patch, there is already > HAVE(SUBVIEWS_IVAR_SPI). Isn’t it just defined improperly? HAVE_SUBVIEWS_IVAR_SPI is defined properly. The SPI is available when deploying to macOS 10.15 or later. When deploying to earlier macOS, the SPI is not available and there is code in WebHTMLView.mm implementing an alternative, but that implementation depends on an ivar declaration. The ivar declaration is not present in the macOS 10.15 and later SDKs. Thus the condition for declaring the ivar in the SPI header is the one stated in the patch. 1577284 25 ap 2019-10-06 20:21:57 -0700 I see, the SPI name confused me into thinking that this macro is about an ivar, which it is not. In this case, what you want is HAVE(SUBVIEWS_IVAR_DECLARED_BY_SDK) for the second part of the condition. 1577396 26 kbr 2019-10-07 11:01:57 -0700 mitz@ thank you for the patch (which builds fine locally) and ap@ thank you for suggesting how to get it to pass the style checker. Locally, this patch builds successfully; ap@, not sure whether it's what you had in mind. Without the change to Platform.h, HAVE(SUBVIEWS_IVAR_DECLARED_BY_SDK) isn't defined. If this looks OK then mitz@ would you like to officially post it? Thanks again for your help! diff --git a/Source/WTF/wtf/Platform.h b/Source/WTF/wtf/Platform.h index 230bfa69843..65706f2ee91 100644 --- a/Source/WTF/wtf/Platform.h +++ b/Source/WTF/wtf/Platform.h @@ -1623,6 +1623,10 @@ #define HAVE_SUBVIEWS_IVAR_SPI 1 #endif +#if PLATFORM(MAC) && __MAC_OS_X_VERSION_MAX_ALLOWED >= 101500 +#define HAVE_SUBVIEWS_IVAR_DECLARED_BY_SDK 1 +#endif + #if PLATFORM(MAC) || (PLATFORM(IOS_FAMILY) && __IPHONE_OS_VERSION_MIN_REQUIRED >= 110000) || PLATFORM(WATCHOS) || PLATFORM(APPLETV) #define USE_PLATFORM_SYSTEM_FALLBACK_LIST 1 #endif diff --git a/Source/WebCore/PAL/pal/spi/mac/NSViewSPI.h b/Source/WebCore/PAL/pal/spi/mac/NSViewSPI.h index e0d5b4e7ca1..1731664e4b8 100644 --- a/Source/WebCore/PAL/pal/spi/mac/NSViewSPI.h +++ b/Source/WebCore/PAL/pal/spi/mac/NSViewSPI.h @@ -29,7 +29,12 @@ #import <pal/spi/cocoa/QuartzCoreSPI.h> -@interface NSView () <CALayerDelegate> +@interface NSView () <CALayerDelegate> { +#if !HAVE(SUBVIEWS_IVAR_SPI) && HAVE(SUBVIEWS_IVAR_DECLARED_BY_SDK) +@package + NSMutableArray<__kindof NSView *> *_subviews; +#endif +} - (NSView *)_findLastViewInKeyViewLoop; 1577425 27 mjs 2019-10-07 12:04:47 -0700 That change looks good, could you post it for review? 1577458 28 ap 2019-10-07 13:26:52 -0700 > ap@, not sure whether it's what you had in mind. Yes, looks great. I'll just go ahead and land it, to cut down on red tape. 1577465 29 380352 ap 2019-10-07 13:33:47 -0700 Created attachment 380352 patch for landing 1577470 30 380352 mitz 2019-10-07 13:37:54 -0700 Comment on attachment 380352 patch for landing View in context: https://bugs.webkit.org/attachment.cgi?id=380352&action=review > Source/WTF/wtf/Platform.h:1627 > +#define HAVE_SUBVIEWS_IVAR_DECLARED_BY_SDK 1 This is confusing. The 10.15 SDK does *not* have a declaration of the subviews ivar. It’s also strange to define this here, where out of context it’s not clear which class it’s about. Consolidating all the logic in NSViewSPI.h would make things more clear. The rule that the style checker is trying to enforce makes little sense here. 1577488 31 380357 ap 2019-10-07 13:51:11 -0700 Created attachment 380357 patch for landing > This is confusing. The 10.15 SDK does *not* have a declaration of the > subviews ivar. Indeed, thank you for catching this. > It’s also strange to define this here, where out of context > it’s not clear which class it’s about. Consolidating all the logic in > NSViewSPI.h would make things more clear. The rule that the style checker is > trying to enforce makes little sense here. The rule is that all versions checks are in Platform.h and similar central files. There were many instances of code where engineers thought that checking versions close to use was better, but moving a subset to Platform.h proved that people were often incorrect about how well they can splatter version checks throughout the code. So now we have this rigid rule. It also helps Apple engineers think twice before doing certain weird things. 1577546 32 kbr 2019-10-07 15:49:10 -0700 https://bugs.webkit.org/attachment.cgi?id=380357 fixes the build problem as well. Thanks again! 1577589 33 380357 commit-queue 2019-10-07 18:02:52 -0700 Comment on attachment 380357 patch for landing Clearing flags on attachment: 380357 Committed r250809: <https://trac.webkit.org/changeset/250809> 1577590 34 commit-queue 2019-10-07 18:02:54 -0700 All reviewed patches have been landed. Closing bug. 1577591 35 webkit-bug-importer 2019-10-07 18:03:19 -0700 <rdar://problem/56058393> 380291 2019-10-05 21:50:07 -0700 2019-10-07 13:33:47 -0700 Untested patch file_199705.txt text/plain 600 mitz SW5kZXg6IFNvdXJjZS9XZWJDb3JlL1BBTC9wYWwvc3BpL21hYy9OU1ZpZXdTUEkuaA0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KLS0tIFNvdXJjZS9XZWJDb3JlL1BBTC9wYWwvc3BpL21hYy9OU1ZpZXdTUEkuaAkocmV2 aXNpb24gMjUwNzY3KQ0KKysrIFNvdXJjZS9XZWJDb3JlL1BBTC9wYWwvc3BpL21hYy9OU1ZpZXdT UEkuaAkod29ya2luZyBjb3B5KQ0KQEAgLTI5LDcgKzI5LDEyIEBADQogDQogI2ltcG9ydCA8cGFs L3NwaS9jb2NvYS9RdWFydHpDb3JlU1BJLmg+DQogDQotQGludGVyZmFjZSBOU1ZpZXcgKCkgPENB TGF5ZXJEZWxlZ2F0ZT4NCitAaW50ZXJmYWNlIE5TVmlldyAoKSA8Q0FMYXllckRlbGVnYXRlPiB7 DQorI2lmICFIQVZFKFNVQlZJRVdTX0lWQVJfU1BJKSAmJiBfX01BQ19PU19YX1ZFUlNJT05fTUFY X0FMTE9XRUQgPj0gMTAxNTAwDQorQHBhY2thZ2UNCisgICAgTlNNdXRhYmxlQXJyYXk8X19raW5k b2YgTlNWaWV3ICo+ICpfc3Vidmlld3M7DQorI2VuZGlmDQorfQ0KIA0KIC0gKE5TVmlldyAqKV9m aW5kTGFzdFZpZXdJbktleVZpZXdMb29wOw0KIA0K 380352 2019-10-07 13:33:47 -0700 2019-10-07 13:51:11 -0700 patch for landing Xcode11fix.txt text/plain 2581 ap SW5kZXg6IFNvdXJjZS9XVEYvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9XVEYvQ2hh bmdlTG9nCShyZXZpc2lvbiAyNTA3ODQpCisrKyBTb3VyY2UvV1RGL0NoYW5nZUxvZwkod29ya2lu ZyBjb3B5KQpAQCAtMSwzICsxLDEzIEBACisyMDE5LTEwLTA3ICBBbGV4ZXkgUHJvc2t1cnlha292 ICA8YXBAYXBwbGUuY29tPgorCisgICAgICAgIEJ1aWxkIGZhaWx1cmUgaW4gV2ViSFRNTFZpZXcu bW0gd2l0aCB0aGUgcHVibGljIFNESyAoWGNvZGUgMTEgYW5kIE1vamF2ZSkKKyAgICAgICAgaHR0 cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTE5OTcwNQorCisgICAgICAgIFBh dGNoIGJ5IERhbiBCZXJuc3RlaW4gYW5kIEtlbm5ldGggUnVzc2VsbC4KKyAgICAgICAgUmV2aWV3 ZWQgYnkgQWxleGV5IFByb3NrdXJ5YWtvdi4KKworICAgICAgICAqIHd0Zi9QbGF0Zm9ybS5oOiBB ZGRlZCBIQVZFX1NVQlZJRVdTX0lWQVJfREVDTEFSRURfQllfU0RLLgorCiAyMDE5LTEwLTA0ICBD b21taXQgUXVldWUgIDxjb21taXQtcXVldWVAd2Via2l0Lm9yZz4KIAogICAgICAgICBVbnJldmll d2VkLCByb2xsaW5nIG91dCByMjUwNzYyLgpJbmRleDogU291cmNlL1dURi93dGYvUGxhdGZvcm0u aAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV1RGL3d0Zi9QbGF0Zm9ybS5oCShyZXZpc2lvbiAyNTA3 ODQpCisrKyBTb3VyY2UvV1RGL3d0Zi9QbGF0Zm9ybS5oCSh3b3JraW5nIGNvcHkpCkBAIC0xNjIz LDYgKzE2MjMsMTAgQEAKICNkZWZpbmUgSEFWRV9TVUJWSUVXU19JVkFSX1NQSSAxCiAjZW5kaWYK IAorI2lmIFBMQVRGT1JNKE1BQykgJiYgX19NQUNfT1NfWF9WRVJTSU9OX01BWF9BTExPV0VEID49 IDEwMTUwMAorI2RlZmluZSBIQVZFX1NVQlZJRVdTX0lWQVJfREVDTEFSRURfQllfU0RLIDEKKyNl bmRpZgorCiAjaWYgUExBVEZPUk0oTUFDKSB8fCAoUExBVEZPUk0oSU9TX0ZBTUlMWSkgJiYgX19J UEhPTkVfT1NfVkVSU0lPTl9NSU5fUkVRVUlSRUQgPj0gMTEwMDAwKSB8fCBQTEFURk9STShXQVRD SE9TKSB8fCBQTEFURk9STShBUFBMRVRWKQogI2RlZmluZSBVU0VfUExBVEZPUk1fU1lTVEVNX0ZB TExCQUNLX0xJU1QgMQogI2VuZGlmCkluZGV4OiBTb3VyY2UvV2ViQ29yZS9QQUwvQ2hhbmdlTG9n Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KLS0tIFNvdXJjZS9XZWJDb3JlL1BBTC9DaGFuZ2VMb2cJKHJldmlzaW9uIDI1 MDc4NCkKKysrIFNvdXJjZS9XZWJDb3JlL1BBTC9DaGFuZ2VMb2cJKHdvcmtpbmcgY29weSkKQEAg LTEsMyArMSwxNCBAQAorMjAxOS0xMC0wNyAgQWxleGV5IFByb3NrdXJ5YWtvdiAgPGFwQGFwcGxl LmNvbT4KKworICAgICAgICBCdWlsZCBmYWlsdXJlIGluIFdlYkhUTUxWaWV3Lm1tIHdpdGggdGhl IHB1YmxpYyBTREsgKFhjb2RlIDExIGFuZCBNb2phdmUpCisgICAgICAgIGh0dHBzOi8vYnVncy53 ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xOTk3MDUKKworICAgICAgICBQYXRjaCBieSBEYW4g QmVybnN0ZWluIGFuZCBLZW5uZXRoIFJ1c3NlbGwuCisgICAgICAgIFJldmlld2VkIGJ5IEFsZXhl eSBQcm9za3VyeWFrb3YuCisKKyAgICAgICAgKiBwYWwvc3BpL21hYy9OU1ZpZXdTUEkuaDogRGVj bGFyZSBfc3Vidmlld3Mgd2hlbiB3ZSBhcmUgbm90IHVzaW5nIHRoZQorICAgICAgICByZXBsYWNl bWVudCBTUEksIGJ1dCB0aGUgU0RLIGRvZXNuJ3QgZGVjbGFyZSB0aGUgaXZhciAoYmVjYXVzZSB0 aGUgU0RLIGlzIHRvbyBuZXcpLgorCiAyMDE5LTEwLTA0ICBBbGV4IENocmlzdGVuc2VuICA8YWNo cmlzdGVuc2VuQHdlYmtpdC5vcmc+CiAKICAgICAgICAgU2ltcGxpZnkgc2FuZGJveCBlbmFibGlu ZyBtYWNyb3MKSW5kZXg6IFNvdXJjZS9XZWJDb3JlL1BBTC9wYWwvc3BpL21hYy9OU1ZpZXdTUEku aAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2ViQ29yZS9QQUwvcGFsL3NwaS9tYWMvTlNWaWV3U1BJ LmgJKHJldmlzaW9uIDI1MDc4NCkKKysrIFNvdXJjZS9XZWJDb3JlL1BBTC9wYWwvc3BpL21hYy9O U1ZpZXdTUEkuaAkod29ya2luZyBjb3B5KQpAQCAtMjksNyArMjksMTIgQEAKIAogI2ltcG9ydCA8 cGFsL3NwaS9jb2NvYS9RdWFydHpDb3JlU1BJLmg+CiAKLUBpbnRlcmZhY2UgTlNWaWV3ICgpIDxD QUxheWVyRGVsZWdhdGU+CitAaW50ZXJmYWNlIE5TVmlldyAoKSA8Q0FMYXllckRlbGVnYXRlPiB7 CisjaWYgIUhBVkUoU1VCVklFV1NfSVZBUl9TUEkpICYmIEhBVkUoU1VCVklFV1NfSVZBUl9ERUNM QVJFRF9CWV9TREspCitAcGFja2FnZQorICAgIE5TTXV0YWJsZUFycmF5PF9fa2luZG9mIE5TVmll dyAqPiAqX3N1YnZpZXdzOworI2VuZGlmCit9CiAKIC0gKE5TVmlldyAqKV9maW5kTGFzdFZpZXdJ bktleVZpZXdMb29wOwogCg== 380357 2019-10-07 13:51:11 -0700 2019-10-07 18:02:52 -0700 patch for landing Xcode11fix.txt text/plain 2581 ap SW5kZXg6IFNvdXJjZS9XVEYvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9XVEYvQ2hh bmdlTG9nCShyZXZpc2lvbiAyNTA3ODQpCisrKyBTb3VyY2UvV1RGL0NoYW5nZUxvZwkod29ya2lu ZyBjb3B5KQpAQCAtMSwzICsxLDEzIEBACisyMDE5LTEwLTA3ICBBbGV4ZXkgUHJvc2t1cnlha292 ICA8YXBAYXBwbGUuY29tPgorCisgICAgICAgIEJ1aWxkIGZhaWx1cmUgaW4gV2ViSFRNTFZpZXcu bW0gd2l0aCB0aGUgcHVibGljIFNESyAoWGNvZGUgMTEgYW5kIE1vamF2ZSkKKyAgICAgICAgaHR0 cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTE5OTcwNQorCisgICAgICAgIFBh dGNoIGJ5IERhbiBCZXJuc3RlaW4gYW5kIEtlbm5ldGggUnVzc2VsbC4KKyAgICAgICAgUmV2aWV3 ZWQgYnkgQWxleGV5IFByb3NrdXJ5YWtvdi4KKworICAgICAgICAqIHd0Zi9QbGF0Zm9ybS5oOiBB ZGRlZCBIQVZFX1NVQlZJRVdTX0lWQVJfREVDTEFSRURfQllfU0RLLgorCiAyMDE5LTEwLTA0ICBD b21taXQgUXVldWUgIDxjb21taXQtcXVldWVAd2Via2l0Lm9yZz4KIAogICAgICAgICBVbnJldmll d2VkLCByb2xsaW5nIG91dCByMjUwNzYyLgpJbmRleDogU291cmNlL1dURi93dGYvUGxhdGZvcm0u aAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV1RGL3d0Zi9QbGF0Zm9ybS5oCShyZXZpc2lvbiAyNTA3 ODQpCisrKyBTb3VyY2UvV1RGL3d0Zi9QbGF0Zm9ybS5oCSh3b3JraW5nIGNvcHkpCkBAIC0xNjIz LDYgKzE2MjMsMTAgQEAKICNkZWZpbmUgSEFWRV9TVUJWSUVXU19JVkFSX1NQSSAxCiAjZW5kaWYK IAorI2lmIFBMQVRGT1JNKE1BQykgJiYgX19NQUNfT1NfWF9WRVJTSU9OX01BWF9BTExPV0VEIDwg MTAxNTAwCisjZGVmaW5lIEhBVkVfU1VCVklFV1NfSVZBUl9ERUNMQVJFRF9CWV9TREsgMQorI2Vu ZGlmCisKICNpZiBQTEFURk9STShNQUMpIHx8IChQTEFURk9STShJT1NfRkFNSUxZKSAmJiBfX0lQ SE9ORV9PU19WRVJTSU9OX01JTl9SRVFVSVJFRCA+PSAxMTAwMDApIHx8IFBMQVRGT1JNKFdBVENI T1MpIHx8IFBMQVRGT1JNKEFQUExFVFYpCiAjZGVmaW5lIFVTRV9QTEFURk9STV9TWVNURU1fRkFM TEJBQ0tfTElTVCAxCiAjZW5kaWYKSW5kZXg6IFNvdXJjZS9XZWJDb3JlL1BBTC9DaGFuZ2VMb2cK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQotLS0gU291cmNlL1dlYkNvcmUvUEFML0NoYW5nZUxvZwkocmV2aXNpb24gMjUw Nzg0KQorKysgU291cmNlL1dlYkNvcmUvUEFML0NoYW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAt MSwzICsxLDE0IEBACisyMDE5LTEwLTA3ICBBbGV4ZXkgUHJvc2t1cnlha292ICA8YXBAYXBwbGUu Y29tPgorCisgICAgICAgIEJ1aWxkIGZhaWx1cmUgaW4gV2ViSFRNTFZpZXcubW0gd2l0aCB0aGUg cHVibGljIFNESyAoWGNvZGUgMTEgYW5kIE1vamF2ZSkKKyAgICAgICAgaHR0cHM6Ly9idWdzLndl YmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTE5OTcwNQorCisgICAgICAgIFBhdGNoIGJ5IERhbiBC ZXJuc3RlaW4gYW5kIEtlbm5ldGggUnVzc2VsbC4KKyAgICAgICAgUmV2aWV3ZWQgYnkgQWxleGV5 IFByb3NrdXJ5YWtvdi4KKworICAgICAgICAqIHBhbC9zcGkvbWFjL05TVmlld1NQSS5oOiBEZWNs YXJlIF9zdWJ2aWV3cyB3aGVuIHdlIGFyZSBub3QgdXNpbmcgdGhlCisgICAgICAgIHJlcGxhY2Vt ZW50IFNQSSwgYnV0IHRoZSBTREsgZG9lc24ndCBkZWNsYXJlIHRoZSBpdmFyIChiZWNhdXNlIHRo ZSBTREsgaXMgdG9vIG5ldykuCisKIDIwMTktMTAtMDQgIEFsZXggQ2hyaXN0ZW5zZW4gIDxhY2hy aXN0ZW5zZW5Ad2Via2l0Lm9yZz4KIAogICAgICAgICBTaW1wbGlmeSBzYW5kYm94IGVuYWJsaW5n IG1hY3JvcwpJbmRleDogU291cmNlL1dlYkNvcmUvUEFML3BhbC9zcGkvbWFjL05TVmlld1NQSS5o Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KLS0tIFNvdXJjZS9XZWJDb3JlL1BBTC9wYWwvc3BpL21hYy9OU1ZpZXdTUEku aAkocmV2aXNpb24gMjUwNzg0KQorKysgU291cmNlL1dlYkNvcmUvUEFML3BhbC9zcGkvbWFjL05T Vmlld1NQSS5oCSh3b3JraW5nIGNvcHkpCkBAIC0yOSw3ICsyOSwxMiBAQAogCiAjaW1wb3J0IDxw YWwvc3BpL2NvY29hL1F1YXJ0ekNvcmVTUEkuaD4KIAotQGludGVyZmFjZSBOU1ZpZXcgKCkgPENB TGF5ZXJEZWxlZ2F0ZT4KK0BpbnRlcmZhY2UgTlNWaWV3ICgpIDxDQUxheWVyRGVsZWdhdGU+IHsK KyNpZiAhSEFWRShTVUJWSUVXU19JVkFSX1NQSSkgJiYgIUhBVkUoU1VCVklFV1NfSVZBUl9ERUNM QVJFRF9CWV9TREspCitAcGFja2FnZQorICAgIE5TTXV0YWJsZUFycmF5PF9fa2luZG9mIE5TVmll dyAqPiAqX3N1YnZpZXdzOworI2VuZGlmCit9CiAKIC0gKE5TVmlldyAqKV9maW5kTGFzdFZpZXdJ bktleVZpZXdMb29wOwogCg==