230384 2021-09-16 20:24:06 -0700 Add MIME type and URL to WebCore::Model to allow processing different model types 2021-09-19 20:28:44 -0700 1 1 1 Unclassified WebKit New Bugs WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED InRadar P2 Normal --- 1 sam sam darin thorton webkit-bug-importer oldest_to_newest 1794320 0 sam 2021-09-16 20:24:06 -0700 Add MIME type and URL to WebCore::Model to allow processing different model types 1794321 1 438435 sam 2021-09-16 20:25:55 -0700 Created attachment 438435 Patch 1794322 2 438435 thorton 2021-09-16 20:27:08 -0700 Comment on attachment 438435 Patch Don't know why it's not r?, but r+ because I have written exactly the same patch :) 1794323 3 438436 sam 2021-09-16 20:27:34 -0700 Created attachment 438436 Patch 1794455 4 sam 2021-09-17 08:56:41 -0700 (In reply to Tim Horton from comment #2) > Comment on attachment 438435 [details] > Patch > > Don't know why it's not r?, but r+ because I have written exactly the same > patch :) Was just waiting for the bots to run before marking r?. Marked now. 1794483 5 438436 darin 2021-09-17 10:10:24 -0700 Comment on attachment 438436 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=438436&action=review > Source/WebCore/platform/graphics/Model.h:33 > #include <wtf/RefCounted.h> > +#include <wtf/URL.h> > +#include <wtf/text/WTFString.h> You can just include URL.h, don’t need the other two. > Source/WebCore/platform/graphics/Model.h:43 > + WEBCORE_EXPORT static Ref<Model> create(Ref<SharedBuffer>, String, URL); Bold trailblazing to use String for a string that we are adopting, as opposed to the more obvious String&& and old school const String&. Does seem simpler than String&& with no obvious disadvantage except for being less explicit. 1794488 6 ews-feeder 2021-09-17 10:18:15 -0700 Committed r282667 (241808@main): <https://commits.webkit.org/241808@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 438436. 1794489 7 webkit-bug-importer 2021-09-17 10:19:16 -0700 <rdar://problem/83246034> 1794502 8 sam 2021-09-17 10:51:47 -0700 (In reply to Darin Adler from comment #5) > Comment on attachment 438436 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=438436&action=review > > > Source/WebCore/platform/graphics/Model.h:33 > > #include <wtf/RefCounted.h> > > +#include <wtf/URL.h> > > +#include <wtf/text/WTFString.h> > > You can just include URL.h, don’t need the other two. Will fix. > > > Source/WebCore/platform/graphics/Model.h:43 > > + WEBCORE_EXPORT static Ref<Model> create(Ref<SharedBuffer>, String, URL); > > Bold trailblazing to use String for a string that we are adopting, as > opposed to the more obvious String&& and old school const String&. Does seem > simpler than String&& with no obvious disadvantage except for being less > explicit. :). This is something I want to explore more deeply. I have a feeling we have a ton of unnecessary ref count churn, especially at the bindings layer, where using "const String&" is the cause. I think there are three cases to consider for String parameters: 1. The function always takes ownership of the string. 2. The function may or may not take ownership of the string. 3. The function never takes ownership of the string. I believe (though I would have to re-convince myself to be sure) "const String&" as a parameter should be reserved for case #2 (though in those cases, I would usually suggest overloading with one taking a "const String&" and one taking a "String", so the move case is still optimal). For #1, "String" should be used. For #3, "const String&" is fine, but we should probably be using StringView in most cases. 1794572 9 darin 2021-09-17 13:11:16 -0700 (In reply to Sam Weinig from comment #8) > I think there are three cases to consider for String parameters: > > 1. The function always takes ownership of the string. > 2. The function may or may not take ownership of the string. > 3. The function never takes ownership of the string. > > I believe (though I would have to re-convince myself to be sure) "const > String&" as a parameter should be reserved for case #2 (though in those > cases, I would usually suggest overloading with one taking a "const String&" > and one taking a "String", so the move case is still optimal). > > For #1, "String" should be used. > For #3, "const String&" is fine, but we should probably be using StringView > in most cases. Three things I can think of: - Why is String better than String&&? We haven’t been consistent about this in WebKit before now and with other objects. I prefer the aesthetics of String. Are there benefits to writing String&& instead? - There’s a variation on #3 worth considering. The function never takes ownership of the string, but does some operation that in turn requires a String, and so if passed a StringView that comes from a String will be less efficient than if it took a String. 1794631 10 darin 2021-09-17 14:52:18 -0700 (sorry forgot the third thing) - The function's interface should not say whether it takes ownership of the string or not, because it's an abstraction and should not expose implementation details. Unclear what is the best thing to do in that case. 1794679 11 sam 2021-09-17 16:26:04 -0700 (In reply to Darin Adler from comment #9) > (In reply to Sam Weinig from comment #8) > > I think there are three cases to consider for String parameters: > > > > 1. The function always takes ownership of the string. > > 2. The function may or may not take ownership of the string. > > 3. The function never takes ownership of the string. > > > > I believe (though I would have to re-convince myself to be sure) "const > > String&" as a parameter should be reserved for case #2 (though in those > > cases, I would usually suggest overloading with one taking a "const String&" > > and one taking a "String", so the move case is still optimal). > > > > For #1, "String" should be used. > > For #3, "const String&" is fine, but we should probably be using StringView > > in most cases. > > Three things I can think of: > > - Why is String better than String&&? We haven’t been consistent about this > in WebKit before now and with other objects. I prefer the aesthetics of > String. Are there benefits to writing String&& instead? String is better than String&& because it will work for both lvalues and rvalues, where as the latter will only worth with rvalues. As a concrete example. The function static void foo(String&& bar) { (void)bar; } with a caller: String string = "hello"; foo(string); will fail to compile with the following error: ... note: candidate function not viable: expects an rvalue for 1st argument static void foo(String&& bar) You would have to call it like: String string = "hello"; foo(WTFMove(string)); which might not be what you want to do. > - There’s a variation on #3 worth considering. The function never takes > ownership of the string, but does some operation that in turn requires a > String, and so if passed a StringView that comes from a String will be less > efficient than if it took a String. Hm, I can't think of a case when this would happen and it wasn't because ownership of a String was needed in some form, but I could totally be wrong. 1794688 12 sam 2021-09-17 16:35:58 -0700 (In reply to Darin Adler from comment #10) > (sorry forgot the third thing) > > - The function's interface should not say whether it takes ownership of the > string or not, because it's an abstraction and should not expose > implementation details. Unclear what is the best thing to do in that case. I mean, I agree, but if we take that to the extreme, we would want to use either "foo(String)" or foo(const String&)" everywhere. However, each has its downsides. "foo(String)" will always cause a ref, unless you explicitly WTFMove() (or otherwise rvalue your way), in which case, you can avoid a ref. "foo(const String&)" allows the implementation decide if it needs to ref, but doesn't allow the caller to "move" the object into it. While sticking to a principle would be nice, I think the efficiency gained by being cognizant of lifetime when choosing parameter types is worth it. 1794696 13 darin 2021-09-17 16:50:26 -0700 (In reply to Sam Weinig from comment #11) > You would have to call it like: > > String string = "hello"; > foo(WTFMove(string)); > > which might not be what you want to do. Or like this: String string = "hello"; foo(String { string }); I’m not saying it’s elegant, but you don’t *have* to move the value in. > > - There’s a variation on #3 worth considering. The function never takes > > ownership of the string, but does some operation that in turn requires a > > String, and so if passed a StringView that comes from a String will be less > > efficient than if it took a String. > > Hm, I can't think of a case when this would happen and it wasn't because > ownership of a String was needed in some form, but I could totally be wrong. The case where this happens without ownership is for a function that looks something up in a hash table that uses a String for entire key or part of the key. We don’t currently support using a StringView for such hash table lookups. String caches the hash across any number of multiple calls to compute it, which StringView will not do. We could add convenient key translation and would lose that optimization. Also worth noting that if the function wants to call any function that currently takes a const String& or String, but should take a StringView, we end up being kind of slow. We won't be converting the entire code base all at once. This means we'd have to do things bottom-up? Any function that makes an AtomString or Identifier, I suppose means it "may or may not take ownership", which is a sort of irritating subtlety. (In reply to Sam Weinig from comment #12) > (In reply to Darin Adler from comment #10) > > - The function's interface should not say whether it takes ownership of the > > string or not, because it's an abstraction and should not expose > > implementation details. Unclear what is the best thing to do in that case. > > I mean, I agree, but if we take that to the extreme, we would want to use > either "foo(String)" or foo(const String&)" everywhere. However, each has > its downsides. I just meant that we should consider when this is the primary concern, not that every function needs to be abstract. 1794964 14 sam 2021-09-19 20:28:44 -0700 (In reply to Darin Adler from comment #13) > (In reply to Sam Weinig from comment #11) > > You would have to call it like: > > > > String string = "hello"; > > foo(WTFMove(string)); > > > > which might not be what you want to do. > > Or like this: > > String string = "hello"; > foo(String { string }); > > I’m not saying it’s elegant, but you don’t *have* to move the value in. > > > > - There’s a variation on #3 worth considering. The function never takes > > > ownership of the string, but does some operation that in turn requires a > > > String, and so if passed a StringView that comes from a String will be less > > > efficient than if it took a String. > > > > Hm, I can't think of a case when this would happen and it wasn't because > > ownership of a String was needed in some form, but I could totally be wrong. > > The case where this happens without ownership is for a function that looks > something up in a hash table that uses a String for entire key or part of > the key. We don’t currently support using a StringView for such hash table > lookups. String caches the hash across any number of multiple calls to > compute it, which StringView will not do. We could add convenient key > translation and would lose that optimization. > I don't feel strongly about the StringView thing, but this makes me think we should consider adding a cache of the string hash to the StringView, and populate it when creating a StringView from a String (and lazily populate it when creating a StringView in another way.) There may be a good reason we haven't done that. 438435 2021-09-16 20:25:55 -0700 2021-09-16 20:27:32 -0700 Patch bug-230384-20210916202554.patch text/plain 4882 sam SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDI4MjYzMSkKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDI0IEBACisyMDIxLTA5LTE2ICBTYW0gV2Vp bmlnICA8d2VpbmlnQGFwcGxlLmNvbT4KKworICAgICAgICBBZGQgTUlNRSB0eXBlIGFuZCBVUkwg dG8gV2ViQ29yZTo6TW9kZWwgdG8gYWxsb3cgcHJvY2Vzc2luZyBkaWZmZXJlbnQgbW9kZWwgdHlw ZXMKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTIzMDM4 NAorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIEFkZHMg TUlNRSB0eXBlIGFuZCBVUkwgdG8gV2ViQ29yZTo6TW9kZWwgdG8gYWxsb3cgcHJvY2Vzc2luZyBk aWZmZXJlbnQgbW9kZWwgdHlwZXMuCisgICAgICAgIFRoaXMgY2hhbmdlIGRvZXMgbm90IHRha2Ug YWR2YW50YXZlIG9mIHRoZW0gKGFuZCB3ZSBzdGlsbCBvbmx5IHN1cHBvcnQgb25lIHR5cGUpCisg ICAgICAgIGJ1dCB0aGlzIHdpbGwgYWxsb3cgdXMgdG8gYWRkIGFkZGl0aW9uYWwgdHlwZXMgZ29p bmcgZm9yd2FyZC4KKworICAgICAgICAqIE1vZHVsZXMvbW9kZWwtZWxlbWVudC9IVE1MTW9kZWxF bGVtZW50LmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OkhUTUxNb2RlbEVsZW1lbnQ6Om5vdGlmeUZp bmlzaGVkKToKKyAgICAgICAgKiBwbGF0Zm9ybS9ncmFwaGljcy9Nb2RlbC5jcHA6CisgICAgICAg IChXZWJDb3JlOjpNb2RlbDo6Y3JlYXRlKToKKyAgICAgICAgKFdlYkNvcmU6Ok1vZGVsOjpNb2Rl bCk6CisgICAgICAgIChXZWJDb3JlOjpvcGVyYXRvcjw8KToKKyAgICAgICAgKiBwbGF0Zm9ybS9n cmFwaGljcy9Nb2RlbC5oOgorICAgICAgICAoV2ViQ29yZTo6TW9kZWw6OmVuY29kZSBjb25zdCk6 CisgICAgICAgIChXZWJDb3JlOjpNb2RlbDo6ZGVjb2RlKToKKwogMjAyMS0wOS0xNiAgU2ltb24g RnJhc2VyICA8c2ltb24uZnJhc2VyQGFwcGxlLmNvbT4KIAogICAgICAgICBGaXggc29tZSBpc3N1 ZXMgd2l0aCB0aGUgY29kZSBwYXRocyB0aGF0IGNhbGwgaW50byBTY3JvbGxBbmltYXRvcjo6Y29u dGVudEFyZWFXaWxsUGFpbnQoKQpJbmRleDogU291cmNlL1dlYkNvcmUvTW9kdWxlcy9tb2RlbC1l bGVtZW50L0hUTUxNb2RlbEVsZW1lbnQuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9XZWJDb3Jl L01vZHVsZXMvbW9kZWwtZWxlbWVudC9IVE1MTW9kZWxFbGVtZW50LmNwcAkocmV2aXNpb24gMjgy NjMxKQorKysgU291cmNlL1dlYkNvcmUvTW9kdWxlcy9tb2RlbC1lbGVtZW50L0hUTUxNb2RlbEVs ZW1lbnQuY3BwCSh3b3JraW5nIGNvcHkpCkBAIC0yMjksNyArMjI5LDcgQEAgdm9pZCBIVE1MTW9k ZWxFbGVtZW50Ojpub3RpZnlGaW5pc2hlZChDYQogICAgIH0KIAogICAgIG1fZGF0YUNvbXBsZXRl ID0gdHJ1ZTsKLSAgICBtX21vZGVsID0gTW9kZWw6OmNyZWF0ZSgqbV9kYXRhKTsKKyAgICBtX21v ZGVsID0gTW9kZWw6OmNyZWF0ZSgqbV9kYXRhLCByZXNvdXJjZS5taW1lVHlwZSgpLCByZXNvdXJj ZS51cmwoKSk7CiAKICAgICBpbnZhbGlkYXRlUmVzb3VyY2VIYW5kbGVBbmRVcGRhdGVSZW5kZXJl cigpOwogCkluZGV4OiBTb3VyY2UvV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGljcy9Nb2RlbC5jcHAK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQotLS0gU291cmNlL1dlYkNvcmUvcGxhdGZvcm0vZ3JhcGhpY3MvTW9kZWwuY3Bw CShyZXZpc2lvbiAyODI2MzEpCisrKyBTb3VyY2UvV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGljcy9N b2RlbC5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTMwLDEzICszMCwxNSBAQAogCiBuYW1lc3BhY2Ug V2ViQ29yZSB7CiAKLVJlZjxNb2RlbD4gTW9kZWw6OmNyZWF0ZShSZWY8U2hhcmVkQnVmZmVyPiBk YXRhKQorUmVmPE1vZGVsPiBNb2RlbDo6Y3JlYXRlKFJlZjxTaGFyZWRCdWZmZXI+IGRhdGEsIFN0 cmluZyBtaW1lVHlwZSwgVVJMIHVybCkKIHsKLSAgICByZXR1cm4gYWRvcHRSZWYoKm5ldyBNb2Rl bChkYXRhKSk7CisgICAgcmV0dXJuIGFkb3B0UmVmKCpuZXcgTW9kZWwoV1RGTW92ZShkYXRhKSwg V1RGTW92ZShtaW1lVHlwZSksIFdURk1vdmUodXJsKSkpOwogfQogCi1Nb2RlbDo6TW9kZWwoUmVm PFNoYXJlZEJ1ZmZlcj4gZGF0YSkKLSAgICA6IG1fZGF0YShkYXRhKQorTW9kZWw6Ok1vZGVsKFJl ZjxTaGFyZWRCdWZmZXI+IGRhdGEsIFN0cmluZyBtaW1lVHlwZSwgVVJMIHVybCkKKyAgICA6IG1f ZGF0YShXVEZNb3ZlKGRhdGEpKQorICAgICwgbV9taW1lVHlwZShXVEZNb3ZlKG1pbWVUeXBlKSkK KyAgICAsIG1fdXJsKFdURk1vdmUodXJsKSkKIHsKIH0KIApAQCAtNDcsNiArNDksOCBAQCBUZXh0 U3RyZWFtJiBvcGVyYXRvcjw8KFRleHRTdHJlYW0mIHRzLCBjCiAgICAgVGV4dFN0cmVhbTo6R3Jv dXBTY29wZSBncm91cFNjb3BlKHRzKTsKICAgICAKICAgICB0cy5kdW1wUHJvcGVydHkoImRhdGEt c2l6ZSIsIG1vZGVsLmRhdGEoKS0+c2l6ZSgpKTsKKyAgICB0cy5kdW1wUHJvcGVydHkoIm1pbWVU eXBlIiwgbW9kZWwubWltZVR5cGUoKSk7CisgICAgdHMuZHVtcFByb3BlcnR5KCJ1cmwiLCBtb2Rl bC51cmwoKSk7CiAgICAgCiAgICAgcmV0dXJuIHRzOwogfQpJbmRleDogU291cmNlL1dlYkNvcmUv cGxhdGZvcm0vZ3JhcGhpY3MvTW9kZWwuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2ViQ29yZS9w bGF0Zm9ybS9ncmFwaGljcy9Nb2RlbC5oCShyZXZpc2lvbiAyODI2MzEpCisrKyBTb3VyY2UvV2Vi Q29yZS9wbGF0Zm9ybS9ncmFwaGljcy9Nb2RlbC5oCSh3b3JraW5nIGNvcHkpCkBAIC0yOSw2ICsy OSw4IEBACiAKICNpbmNsdWRlICJTaGFyZWRCdWZmZXIuaCIKICNpbmNsdWRlIDx3dGYvUmVmQ291 bnRlZC5oPgorI2luY2x1ZGUgPHd0Zi9VUkwuaD4KKyNpbmNsdWRlIDx3dGYvdGV4dC9XVEZTdHJp bmcuaD4KIAogbmFtZXNwYWNlIFdURiB7CiBjbGFzcyBUZXh0U3RyZWFtOwpAQCAtMzgsMTggKzQw LDIyIEBAIG5hbWVzcGFjZSBXZWJDb3JlIHsKIAogY2xhc3MgTW9kZWwgZmluYWwgOiBwdWJsaWMg UmVmQ291bnRlZDxNb2RlbD4gewogcHVibGljOgotICAgIFdFQkNPUkVfRVhQT1JUIHN0YXRpYyBS ZWY8TW9kZWw+IGNyZWF0ZShSZWY8U2hhcmVkQnVmZmVyPik7CisgICAgV0VCQ09SRV9FWFBPUlQg c3RhdGljIFJlZjxNb2RlbD4gY3JlYXRlKFJlZjxTaGFyZWRCdWZmZXI+LCBTdHJpbmcsIFVSTCk7 CiAgICAgV0VCQ09SRV9FWFBPUlQgfk1vZGVsKCk7CiAKICAgICBSZWY8U2hhcmVkQnVmZmVyPiBk YXRhKCkgY29uc3QgeyByZXR1cm4gbV9kYXRhOyB9CisgICAgY29uc3QgU3RyaW5nJiBtaW1lVHlw ZSgpIGNvbnN0IHsgcmV0dXJuIG1fbWltZVR5cGU7IH0KKyAgICBjb25zdCBVUkwmIHVybCgpIGNv bnN0IHsgcmV0dXJuIG1fdXJsOyB9CiAgICAgCiAgICAgdGVtcGxhdGU8Y2xhc3MgRW5jb2Rlcj4g dm9pZCBlbmNvZGUoRW5jb2RlciYpIGNvbnN0OwogICAgIHRlbXBsYXRlPGNsYXNzIERlY29kZXI+ IHN0YXRpYyBSZWZQdHI8TW9kZWw+IGRlY29kZShEZWNvZGVyJik7CiAKIHByaXZhdGU6Ci0gICAg ZXhwbGljaXQgTW9kZWwoUmVmPFNoYXJlZEJ1ZmZlcj4pOworICAgIGV4cGxpY2l0IE1vZGVsKFJl ZjxTaGFyZWRCdWZmZXI+LCBTdHJpbmcsIFVSTCk7CiAKICAgICBSZWY8U2hhcmVkQnVmZmVyPiBt X2RhdGE7CisgICAgU3RyaW5nIG1fbWltZVR5cGU7CisgICAgVVJMIG1fdXJsOwogfTsKIAogdGVt cGxhdGU8Y2xhc3MgRW5jb2Rlcj4KQEAgLTU3LDYgKzYzLDggQEAgdm9pZCBNb2RlbDo6ZW5jb2Rl KEVuY29kZXImIGVuY29kZXIpIGNvbgogewogICAgIGVuY29kZXIgPDwgc3RhdGljX2Nhc3Q8c2l6 ZV90PihtX2RhdGEtPnNpemUoKSk7CiAgICAgZW5jb2Rlci5lbmNvZGVGaXhlZExlbmd0aERhdGEo bV9kYXRhLT5kYXRhKCksIG1fZGF0YS0+c2l6ZSgpLCAxKTsKKyAgICBlbmNvZGVyIDw8IG1fbWlt ZVR5cGU7CisgICAgZW5jb2RlciA8PCBtX3VybDsKIH0KIAogdGVtcGxhdGU8Y2xhc3MgRGVjb2Rl cj4KQEAgLTc3LDcgKzg1LDE3IEBAIFJlZlB0cjxNb2RlbD4gTW9kZWw6OmRlY29kZShEZWNvZGVy JiBkZWMKICAgICBpZiAoIWRlY29kZXIuZGVjb2RlRml4ZWRMZW5ndGhEYXRhKGRhdGEuZGF0YSgp LCBkYXRhLnNpemUoKSwgMSkpCiAgICAgICAgIHJldHVybiBudWxscHRyOwogCi0gICAgcmV0dXJu IE1vZGVsOjpjcmVhdGUoU2hhcmVkQnVmZmVyOjpjcmVhdGUoV1RGTW92ZShkYXRhKSkpOworICAg IHN0ZDo6b3B0aW9uYWw8U3RyaW5nPiBtaW1lVHlwZTsKKyAgICBkZWNvZGVyID4+IG1pbWVUeXBl OworICAgIGlmICghbWltZVR5cGUpCisgICAgICAgIHJldHVybiBudWxscHRyOworCisgICAgc3Rk OjpvcHRpb25hbDxVUkw+IHVybDsKKyAgICBkZWNvZGVyID4+IHVybDsKKyAgICBpZiAoIXVybCkK KyAgICAgICAgcmV0dXJuIG51bGxwdHI7CisKKyAgICByZXR1cm4gTW9kZWw6OmNyZWF0ZShTaGFy ZWRCdWZmZXI6OmNyZWF0ZShXVEZNb3ZlKGRhdGEpKSwgV1RGTW92ZSgqbWltZVR5cGUpLCBXVEZN b3ZlKCp1cmwpKTsKIH0KIAogV0VCQ09SRV9FWFBPUlQgV1RGOjpUZXh0U3RyZWFtJiBvcGVyYXRv cjw8KFdURjo6VGV4dFN0cmVhbSYsIGNvbnN0IE1vZGVsJik7Cg== 438436 2021-09-16 20:27:34 -0700 2021-09-17 10:18:16 -0700 Patch bug-230384-20210916202733.patch text/plain 4939 sam SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDI4MjYzMSkKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDI0IEBACisyMDIxLTA5LTE2ICBTYW0gV2Vp bmlnICA8d2VpbmlnQGFwcGxlLmNvbT4KKworICAgICAgICBBZGQgTUlNRSB0eXBlIGFuZCBVUkwg dG8gV2ViQ29yZTo6TW9kZWwgdG8gYWxsb3cgcHJvY2Vzc2luZyBkaWZmZXJlbnQgbW9kZWwgdHlw ZXMKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTIzMDM4 NAorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIEFkZHMg TUlNRSB0eXBlIGFuZCBVUkwgdG8gV2ViQ29yZTo6TW9kZWwgdG8gYWxsb3cgcHJvY2Vzc2luZyBk aWZmZXJlbnQgbW9kZWwgdHlwZXMuCisgICAgICAgIFRoaXMgY2hhbmdlIGRvZXMgbm90IHRha2Ug YWR2YW50YXZlIG9mIHRoZW0gKGFuZCB3ZSBzdGlsbCBvbmx5IHN1cHBvcnQgb25lIHR5cGUpCisg ICAgICAgIGJ1dCB0aGlzIHdpbGwgYWxsb3cgdXMgdG8gYWRkIGFkZGl0aW9uYWwgdHlwZXMgZ29p bmcgZm9yd2FyZC4KKworICAgICAgICAqIE1vZHVsZXMvbW9kZWwtZWxlbWVudC9IVE1MTW9kZWxF bGVtZW50LmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OkhUTUxNb2RlbEVsZW1lbnQ6Om5vdGlmeUZp bmlzaGVkKToKKyAgICAgICAgKiBwbGF0Zm9ybS9ncmFwaGljcy9Nb2RlbC5jcHA6CisgICAgICAg IChXZWJDb3JlOjpNb2RlbDo6Y3JlYXRlKToKKyAgICAgICAgKFdlYkNvcmU6Ok1vZGVsOjpNb2Rl bCk6CisgICAgICAgIChXZWJDb3JlOjpvcGVyYXRvcjw8KToKKyAgICAgICAgKiBwbGF0Zm9ybS9n cmFwaGljcy9Nb2RlbC5oOgorICAgICAgICAoV2ViQ29yZTo6TW9kZWw6OmVuY29kZSBjb25zdCk6 CisgICAgICAgIChXZWJDb3JlOjpNb2RlbDo6ZGVjb2RlKToKKwogMjAyMS0wOS0xNiAgU2ltb24g RnJhc2VyICA8c2ltb24uZnJhc2VyQGFwcGxlLmNvbT4KIAogICAgICAgICBGaXggc29tZSBpc3N1 ZXMgd2l0aCB0aGUgY29kZSBwYXRocyB0aGF0IGNhbGwgaW50byBTY3JvbGxBbmltYXRvcjo6Y29u dGVudEFyZWFXaWxsUGFpbnQoKQpJbmRleDogU291cmNlL1dlYkNvcmUvTW9kdWxlcy9tb2RlbC1l bGVtZW50L0hUTUxNb2RlbEVsZW1lbnQuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9XZWJDb3Jl L01vZHVsZXMvbW9kZWwtZWxlbWVudC9IVE1MTW9kZWxFbGVtZW50LmNwcAkocmV2aXNpb24gMjgy NjMxKQorKysgU291cmNlL1dlYkNvcmUvTW9kdWxlcy9tb2RlbC1lbGVtZW50L0hUTUxNb2RlbEVs ZW1lbnQuY3BwCSh3b3JraW5nIGNvcHkpCkBAIC0yMjksNyArMjI5LDcgQEAgdm9pZCBIVE1MTW9k ZWxFbGVtZW50Ojpub3RpZnlGaW5pc2hlZChDYQogICAgIH0KIAogICAgIG1fZGF0YUNvbXBsZXRl ID0gdHJ1ZTsKLSAgICBtX21vZGVsID0gTW9kZWw6OmNyZWF0ZSgqbV9kYXRhKTsKKyAgICBtX21v ZGVsID0gTW9kZWw6OmNyZWF0ZSgqbV9kYXRhLCByZXNvdXJjZS5taW1lVHlwZSgpLCByZXNvdXJj ZS51cmwoKSk7CiAKICAgICBpbnZhbGlkYXRlUmVzb3VyY2VIYW5kbGVBbmRVcGRhdGVSZW5kZXJl cigpOwogCkluZGV4OiBTb3VyY2UvV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGljcy9Nb2RlbC5jcHAK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQotLS0gU291cmNlL1dlYkNvcmUvcGxhdGZvcm0vZ3JhcGhpY3MvTW9kZWwuY3Bw CShyZXZpc2lvbiAyODI2MzEpCisrKyBTb3VyY2UvV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGljcy9N b2RlbC5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTMwLDEzICszMCwxNSBAQAogCiBuYW1lc3BhY2Ug V2ViQ29yZSB7CiAKLVJlZjxNb2RlbD4gTW9kZWw6OmNyZWF0ZShSZWY8U2hhcmVkQnVmZmVyPiBk YXRhKQorUmVmPE1vZGVsPiBNb2RlbDo6Y3JlYXRlKFJlZjxTaGFyZWRCdWZmZXI+IGRhdGEsIFN0 cmluZyBtaW1lVHlwZSwgVVJMIHVybCkKIHsKLSAgICByZXR1cm4gYWRvcHRSZWYoKm5ldyBNb2Rl bChkYXRhKSk7CisgICAgcmV0dXJuIGFkb3B0UmVmKCpuZXcgTW9kZWwoV1RGTW92ZShkYXRhKSwg V1RGTW92ZShtaW1lVHlwZSksIFdURk1vdmUodXJsKSkpOwogfQogCi1Nb2RlbDo6TW9kZWwoUmVm PFNoYXJlZEJ1ZmZlcj4gZGF0YSkKLSAgICA6IG1fZGF0YShkYXRhKQorTW9kZWw6Ok1vZGVsKFJl ZjxTaGFyZWRCdWZmZXI+IGRhdGEsIFN0cmluZyBtaW1lVHlwZSwgVVJMIHVybCkKKyAgICA6IG1f ZGF0YShXVEZNb3ZlKGRhdGEpKQorICAgICwgbV9taW1lVHlwZShXVEZNb3ZlKG1pbWVUeXBlKSkK KyAgICAsIG1fdXJsKFdURk1vdmUodXJsKSkKIHsKIH0KIApAQCAtNDUsOSArNDcsMTEgQEAgTW9k ZWw6On5Nb2RlbCgpID0gZGVmYXVsdDsKIFRleHRTdHJlYW0mIG9wZXJhdG9yPDwoVGV4dFN0cmVh bSYgdHMsIGNvbnN0IE1vZGVsJiBtb2RlbCkKIHsKICAgICBUZXh0U3RyZWFtOjpHcm91cFNjb3Bl IGdyb3VwU2NvcGUodHMpOwotICAgIAorCiAgICAgdHMuZHVtcFByb3BlcnR5KCJkYXRhLXNpemUi LCBtb2RlbC5kYXRhKCktPnNpemUoKSk7Ci0gICAgCisgICAgdHMuZHVtcFByb3BlcnR5KCJtaW1l LXR5cGUiLCBtb2RlbC5taW1lVHlwZSgpKTsKKyAgICB0cy5kdW1wUHJvcGVydHkoInVybCIsIG1v ZGVsLnVybCgpKTsKKwogICAgIHJldHVybiB0czsKIH0KIApJbmRleDogU291cmNlL1dlYkNvcmUv cGxhdGZvcm0vZ3JhcGhpY3MvTW9kZWwuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2ViQ29yZS9w bGF0Zm9ybS9ncmFwaGljcy9Nb2RlbC5oCShyZXZpc2lvbiAyODI2MzEpCisrKyBTb3VyY2UvV2Vi Q29yZS9wbGF0Zm9ybS9ncmFwaGljcy9Nb2RlbC5oCSh3b3JraW5nIGNvcHkpCkBAIC0yOSw2ICsy OSw4IEBACiAKICNpbmNsdWRlICJTaGFyZWRCdWZmZXIuaCIKICNpbmNsdWRlIDx3dGYvUmVmQ291 bnRlZC5oPgorI2luY2x1ZGUgPHd0Zi9VUkwuaD4KKyNpbmNsdWRlIDx3dGYvdGV4dC9XVEZTdHJp bmcuaD4KIAogbmFtZXNwYWNlIFdURiB7CiBjbGFzcyBUZXh0U3RyZWFtOwpAQCAtMzgsMTggKzQw LDIyIEBAIG5hbWVzcGFjZSBXZWJDb3JlIHsKIAogY2xhc3MgTW9kZWwgZmluYWwgOiBwdWJsaWMg UmVmQ291bnRlZDxNb2RlbD4gewogcHVibGljOgotICAgIFdFQkNPUkVfRVhQT1JUIHN0YXRpYyBS ZWY8TW9kZWw+IGNyZWF0ZShSZWY8U2hhcmVkQnVmZmVyPik7CisgICAgV0VCQ09SRV9FWFBPUlQg c3RhdGljIFJlZjxNb2RlbD4gY3JlYXRlKFJlZjxTaGFyZWRCdWZmZXI+LCBTdHJpbmcsIFVSTCk7 CiAgICAgV0VCQ09SRV9FWFBPUlQgfk1vZGVsKCk7CiAKICAgICBSZWY8U2hhcmVkQnVmZmVyPiBk YXRhKCkgY29uc3QgeyByZXR1cm4gbV9kYXRhOyB9CisgICAgY29uc3QgU3RyaW5nJiBtaW1lVHlw ZSgpIGNvbnN0IHsgcmV0dXJuIG1fbWltZVR5cGU7IH0KKyAgICBjb25zdCBVUkwmIHVybCgpIGNv bnN0IHsgcmV0dXJuIG1fdXJsOyB9CiAgICAgCiAgICAgdGVtcGxhdGU8Y2xhc3MgRW5jb2Rlcj4g dm9pZCBlbmNvZGUoRW5jb2RlciYpIGNvbnN0OwogICAgIHRlbXBsYXRlPGNsYXNzIERlY29kZXI+ IHN0YXRpYyBSZWZQdHI8TW9kZWw+IGRlY29kZShEZWNvZGVyJik7CiAKIHByaXZhdGU6Ci0gICAg ZXhwbGljaXQgTW9kZWwoUmVmPFNoYXJlZEJ1ZmZlcj4pOworICAgIGV4cGxpY2l0IE1vZGVsKFJl ZjxTaGFyZWRCdWZmZXI+LCBTdHJpbmcsIFVSTCk7CiAKICAgICBSZWY8U2hhcmVkQnVmZmVyPiBt X2RhdGE7CisgICAgU3RyaW5nIG1fbWltZVR5cGU7CisgICAgVVJMIG1fdXJsOwogfTsKIAogdGVt cGxhdGU8Y2xhc3MgRW5jb2Rlcj4KQEAgLTU3LDYgKzYzLDggQEAgdm9pZCBNb2RlbDo6ZW5jb2Rl KEVuY29kZXImIGVuY29kZXIpIGNvbgogewogICAgIGVuY29kZXIgPDwgc3RhdGljX2Nhc3Q8c2l6 ZV90PihtX2RhdGEtPnNpemUoKSk7CiAgICAgZW5jb2Rlci5lbmNvZGVGaXhlZExlbmd0aERhdGEo bV9kYXRhLT5kYXRhKCksIG1fZGF0YS0+c2l6ZSgpLCAxKTsKKyAgICBlbmNvZGVyIDw8IG1fbWlt ZVR5cGU7CisgICAgZW5jb2RlciA8PCBtX3VybDsKIH0KIAogdGVtcGxhdGU8Y2xhc3MgRGVjb2Rl cj4KQEAgLTc3LDcgKzg1LDE3IEBAIFJlZlB0cjxNb2RlbD4gTW9kZWw6OmRlY29kZShEZWNvZGVy JiBkZWMKICAgICBpZiAoIWRlY29kZXIuZGVjb2RlRml4ZWRMZW5ndGhEYXRhKGRhdGEuZGF0YSgp LCBkYXRhLnNpemUoKSwgMSkpCiAgICAgICAgIHJldHVybiBudWxscHRyOwogCi0gICAgcmV0dXJu IE1vZGVsOjpjcmVhdGUoU2hhcmVkQnVmZmVyOjpjcmVhdGUoV1RGTW92ZShkYXRhKSkpOworICAg IHN0ZDo6b3B0aW9uYWw8U3RyaW5nPiBtaW1lVHlwZTsKKyAgICBkZWNvZGVyID4+IG1pbWVUeXBl OworICAgIGlmICghbWltZVR5cGUpCisgICAgICAgIHJldHVybiBudWxscHRyOworCisgICAgc3Rk OjpvcHRpb25hbDxVUkw+IHVybDsKKyAgICBkZWNvZGVyID4+IHVybDsKKyAgICBpZiAoIXVybCkK KyAgICAgICAgcmV0dXJuIG51bGxwdHI7CisKKyAgICByZXR1cm4gTW9kZWw6OmNyZWF0ZShTaGFy ZWRCdWZmZXI6OmNyZWF0ZShXVEZNb3ZlKGRhdGEpKSwgV1RGTW92ZSgqbWltZVR5cGUpLCBXVEZN b3ZlKCp1cmwpKTsKIH0KIAogV0VCQ09SRV9FWFBPUlQgV1RGOjpUZXh0U3RyZWFtJiBvcGVyYXRv cjw8KFdURjo6VGV4dFN0cmVhbSYsIGNvbnN0IE1vZGVsJik7Cg==