28117 2009-08-08 21:02:10 -0700 Native JSON.stringify does not omit functions 2009-08-13 13:27:24 -0700 1 1 1 Unclassified WebKit JavaScriptCore 528+ (Nightly build) Mac (Intel) OS X 10.5 RESOLVED FIXED http://lucassmith.name/pub/JSON-test-suite/test.html HasReduction, InRadar P2 Normal --- 0 lsmith webkit-unassigned brendan kangax oliver rspeyer ryan oldest_to_newest 138465 0 lsmith 2009-08-08 21:02:10 -0700 JSON does not define functions. They should be treated in the same manner as undefined, omitted in objects and replaced by null in arrays. Nightly r46919 stringifies functions as objects. JSON.stringify({fn:function () {}}) should return '{}' but returns '{"fn":{}}' in the nightly. 138547 1 mrowe 2009-08-09 13:36:52 -0700 <rdar://problem/7129375> 138551 2 oliver 2009-08-09 13:44:14 -0700 This is a bug in firefox. Functions are an object, and therefore should be emitted, per section 15.12.3 of es262-5 138553 3 oliver 2009-08-09 13:57:10 -0700 https://bugzilla.mozilla.org/show_bug.cgi?id=509339 138584 4 lsmith 2009-08-09 20:31:50 -0700 Per the final draft of the ECMA 5 spec located at http://www.ecma-international.org/publications/files/drafts/tc39-2009-025.pdf Section 15.12.3 states in the definition of the Str abstract function 4. If value is null then return "null". 5. If value is true then return "true". 6. If value is false then return "false". 7. If Type(value) is object then, a. If the [[Class]] internal property of value is "Number" then, i. Let value be ToNumber(value). b. Else if the [[Class]] internal property of value is "String" then, i. Let value be ToString(value). 8. If Type(value) is string, then return the result of calling the abstract operation Quote with argument value. 9. If Type(value) is number a. If value is finite then return ToString(value). b. else, return "null". 10. If Type(value) is object, and IsCallable(value) is false a. If the [[Class]] internal property of value is "Array" then i. Return the result of calling the abstract operation JA with argument value. b. Return the result of calling the abstract operation JO with argument value. 11. Return undefined. Note 10. and IsCallable(value) is false Also, every implementation of JSON including the reference implementation by Douglas Crockford treats functions as it would undefined. From Crockford's http://json.org/json2.js "Values that do not have JSON representations, such as undefined or functions, will not be serialized. Such values in objects will be dropped; in arrays they will be replaced with null. You can use a replacer function to replace those with JSON values. JSON.stringify(undefined) returns undefined." From http://json.org/js.html "Values that do not have a representation in JSON (such as functions and undefined) are excluded." 138585 5 oliver 2009-08-09 20:47:54 -0700 Ah indeed. That makes me sad. 139228 6 34637 oliver 2009-08-11 21:43:54 -0700 Created attachment 34637 Patch v1 139230 7 oliver 2009-08-11 21:57:36 -0700 Committed r47086 139257 8 34637 darin 2009-08-11 22:54:33 -0700 Comment on attachment 34637 Patch v1 Why not use inherits(&InternalFunction::info) instead of calling getCallData and then special-casing JSArray? 139261 9 oliver 2009-08-11 23:04:59 -0700 (In reply to comment #8) > (From update of attachment 34637 [details]) > Why not use inherits(&InternalFunction::info) instead of calling getCallData > and then special-casing JSArray? The uses the IsCallable internal function -- inheriting from InternalFunction is not a sufficient check, but now i've tested firefox with a regex, /a/, they clearly are ignoring IsCallable *yay* 139373 10 lsmith 2009-08-12 09:49:26 -0700 What was the test against FF? RegExp should return false to IsCallable. Safari and webkit have been incorrectly reporting typeof /a/ === 'function' for several versions. 139444 11 oliver 2009-08-12 11:27:45 -0700 (In reply to comment #10) > What was the test against FF? RegExp should return false to IsCallable. > Safari and webkit have been incorrectly reporting typeof /a/ === 'function' for > several versions. RegExps are callable -- eg. /b/("abc") -- the regex is callable, that means that the internal property IsCallable() must return true, which means that regexps should not be serialised. 139718 12 lsmith 2009-08-12 21:45:52 -0700 I was unaware of this feature until reading your comment. This behavior is not in the spec. section 9.11 specifies IsCallable If the argument object has an [[Call]] internal method, then return true, otherwise return false. The only references in the spec to setting the [[Call]] internal method are 13.2 Creating Function objects 13.2.3 The [[ThrowTypeError]] Function Object 15.3.4.5 Function.prototype.bind (thisArg [, arg1 [, arg2, …]]) Section 15.10.6, defining RegExp, states The value of the [[Prototype]] internal property of the RegExp prototype object is the standard built-in Object prototype object (15.2.4) I found that /a/("abc") is implemented (inconsistently) in Firefox 3.0, Firefox 3.5, Safari 3.2.1, Safari 4, Opera 9.6.3, Opera 10 beta2, Chrome 3 beta, and the WebKit nightlies. It is not implemented in IE6, IE7, IE8, or Chrome 2. Mozilla identifies this feature as a JavaScript extension https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/RegExp#RegExp_instances I infer that such is the case for the others, WebKit included. The difference here being that the other browser vendors prevent the spec deviation from rippling through their implementation to (at least) typeof and recently to JSON.stringify. Currently native JSON support is present in Firefox 3.5, IE8, Chrome 3 beta, and recent WebKit nightlies. All three of the other currently implementing browsers agree both that typeof /a/ == 'object' and JSON.stringify(/a/) == '{}'. There is value in interoperability. If not typeof, please at least stringify RegExp instances as objects for the sake of convention. 139728 13 oliver 2009-08-12 22:26:10 -0700 > Currently native JSON support is present in Firefox 3.5, IE8, Chrome 3 beta, > and recent WebKit nightlies. All three of the other currently implementing > browsers agree both that typeof /a/ == 'object' and JSON.stringify(/a/) == > '{}'. There is value in interoperability. If not typeof, please at least > stringify RegExp instances as objects for the sake of convention. RegExps are callable -- breaking this would break compatibility with json2.js, and the bug is in mozilla for not correctly treating a callable object as callable. We cannot reasonably serialise regexps as standard objects -- the bug is in firefox, not webkit. 139737 14 lsmith 2009-08-12 23:26:37 -0700 > breaking this would break compatibility with json2.js Can you explain this? 139738 15 rspeyer 2009-08-12 23:45:40 -0700 (In reply to comment #13) > RegExps are callable -- breaking this would break compatibility with json2.js, > and the bug is in mozilla for not correctly treating a callable object as > callable. I think there is an important distinction between a vendor extension to EcmaScript to allow an object to be treated as a function, and the meaning of IsCallable in the spec. As Luke mentioned above, according to the spec, a IsCallable is false for RegExp's, and thus they should be serialised by JSON.stringify, in 15.12.3 step 10. 139739 16 rspeyer 2009-08-12 23:48:32 -0700 (In reply to comment #15) > As Luke mentioned above, according to the spec, a IsCallable is false for > RegExp's, and thus they should be serialised by JSON.stringify, in 15.12.3 step > 10. That is, step 10 of the Str operation. 139742 17 oliver 2009-08-13 00:19:20 -0700 (In reply to comment #16) > (In reply to comment #15) > > > As Luke mentioned above, according to the spec, a IsCallable is false for > > RegExp's, and thus they should be serialised by JSON.stringify, in 15.12.3 step > > 10. > > That is, step 10 of the Str operation. json2.js uses typeof holder === "function" to determine whether an object IsCallable, and regexp instances have the type "function". This is correct behaviour, per ES5 (from ES262, v5, 11.4.3) Object (native and doesn‘t implement [[Call]]) -> "object" Object (native or host and implements [[Call]]) -> "function" IsCallable is defined in section 9.11: If the argument object has an [[Call]] internal method, then return true, otherwise return false. In other words, a RegExp instance has [[Call]] so typeof should be "function", and [[IsCallable]] is true. You seem to believe that there is value in serialising a regexp object, when there is not -- a serialised regexp object is either undefined (in conforming implementations in which regexps are callable) or as the empty object {} (in conforming implementations in whichs regexps are not callable). Firefox is not conforming in this regard. Arguing will not accopmlish anything as it is pointless to add a slow check which will break behaviour relative to json2, just to handle the specific case of RegExps, when there are numerous other disagreements between different runtimes as to which objects are callable (NodeLists anyone?), especially given the serialisation of RegExps is unhelpful in either case. If you feel really strongly about this, i suggest you go to http://bugs.mozilla.org and file a bug on the spidermonkey RegExp object incorrectly reporting typeof as "object" and claiming not to be callable. 139746 18 rspeyer 2009-08-13 00:56:17 -0700 (In reply to comment #17) > > json2.js uses typeof holder === "function" to determine whether an object > IsCallable, That seems reasonable to me. > and regexp instances have the type "function". I think this is the crux of the issue. I know that webkit gives typeof /a/ === 'function', but I don't understand why. The spec does not say anywhere that a RegExp defines the internal property [[Call]]. > This is correct > behaviour, per ES5 (from ES262, v5, 11.4.3) > Object (native and doesn‘t implement [[Call]]) -> "object" > Object (native or host and implements [[Call]]) -> "function" > Exactly. So, wouldn't RegExp's fall into the first category? Yes, they can be treated as functions, but that's a particular vendor extension, it's not how RegExp instances are specified to behave. > IsCallable is defined in section 9.11: > If the argument object has an [[Call]] internal method, then return true, > otherwise > return false. Right, and again, as per the spec, a RegExp does not have a [[Call]] internal method. > > In other words, a RegExp instance has [[Call]] so typeof should be "function", > and [[IsCallable]] is true. > I think we forked back at /a/('a') implying that at a specification level, [[Call]] is defined for RegExp's. > You seem to believe that there is value in serialising a regexp object, when > there is not -- a serialised regexp object is either undefined (in conforming > implementations in which regexps are callable) or as the empty object {} (in > conforming implementations in whichs regexps are not callable). > Granted, it's not going to be typical, and I can't actually think of a very good use case for it myself. However enumerable properties can be defined on RegExp's or their prototype, as can the toJSON method. I think this is more about conformance with the spec. > Firefox is not conforming in this regard. Arguing will not accopmlish anything > as it is pointless to add a slow check which will break behaviour relative to > json2, just to handle the specific case of RegExps, when there are numerous > other disagreements between different runtimes as to which objects are callable > (NodeLists anyone?), especially given the serialisation of RegExps is unhelpful > in either case. > > If you feel really strongly about this, i suggest you go to > http://bugs.mozilla.org and file a bug on the spidermonkey RegExp object > incorrectly reporting typeof as "object" and claiming not to be callable. Well, as I said above, as far as I can tell, the spec says that RegExp is not callable, in the sense that the internal [[Call]] property is not defined, IsCallable will return false and thus at the language level, typeof should return 'object', and stringify should not ignore it. 139795 19 kangax 2009-08-13 04:40:09 -0700 (In reply to comment #18) > (In reply to comment #17) [...] > > Firefox is not conforming in this regard. Arguing will not accopmlish anything > > as it is pointless to add a slow check which will break behaviour relative to > > json2, just to handle the specific case of RegExps, when there are numerous > > other disagreements between different runtimes as to which objects are callable > > (NodeLists anyone?), especially given the serialisation of RegExps is unhelpful > > in either case. > > > > If you feel really strongly about this, i suggest you go to > > http://bugs.mozilla.org and file a bug on the spidermonkey RegExp object > > incorrectly reporting typeof as "object" and claiming not to be callable. > > Well, as I said above, as far as I can tell, the spec says that RegExp is not > callable, in the sense that the internal [[Call]] property is not defined, > IsCallable will return false and thus at the language level, typeof should > return 'object', and stringify should not ignore it. Yes, at the "language level" `RegExp` objects don't have [[Call]], but don't forget that ES3 allows implementations to extend language and still be considered conforming. Quoting section 2: | A conforming implementation of ECMAScript is permitted to provide | additional types, values, objects, properties, and functions beyond those | described in this specification. In particular, a conforming implementation | of ECMAScript is permitted to provide properties not described in this | specification, and values for those properties, for objects that are | described in this specification. So here we are with a conforming implementation that adds [[Call]] to RegExp objects. Note that nowhere does ES3 explicitly disallow for `RegExp` objects to have [[Call]] as it does for, say, `Math` or "Global object". 139832 20 rspeyer 2009-08-13 07:20:53 -0700 (In reply to comment #19) > (In reply to comment #18) > > (In reply to comment #17) > [...] > > > > Well, as I said above, as far as I can tell, the spec says that RegExp is not > > callable, in the sense that the internal [[Call]] property is not defined, > > IsCallable will return false and thus at the language level, typeof should > > return 'object', and stringify should not ignore it. > > Yes, at the "language level" `RegExp` objects don't have [[Call]], but don't > forget that ES3 allows implementations to extend language and still be > considered conforming. Quoting section 2: > > | A conforming implementation of ECMAScript is permitted to provide > | additional types, values, objects, properties, and functions beyond those > | described in this specification. In particular, a conforming implementation > | of ECMAScript is permitted to provide properties not described in this > | specification, and values for those properties, for objects that are > | described in this specification. > > So here we are with a conforming implementation that adds [[Call]] to RegExp > objects. Note that nowhere does ES3 explicitly disallow for `RegExp` objects to > have [[Call]] as it does for, say, `Math` or "Global object". Good points. I guess to some extent it's a matter of interpretation here. To me /a/('abc') just looks like syntactic sugar for /a/.exec('abc'). /a/ is certainly not a member of the "function" objects described in section 13 or 15.3 of the spec. The view that it's simply (unspecified) syntactic sugar, and doesn't change anything about the runtime behaviour seems to be Mozilla's approach. On the other hand, WebKit seem to have taken it as both additional syntax and also a semantic change such that while a RegExp instance is not a function as in "/a/ instanceof Function", it does have an internal [[Call]] property, which is called by this new syntax. Perhaps that view is just as valid, but it does alter the behaviour of syntactically identical programs. It's hard to tell who's right because this behaviour was never specified to begin with. I guess there's not much more for me I can say here. This sort of thing is best clarified, and specified (or explicitly not specified) by the TC39 commitee. 139875 21 brendan 2009-08-13 09:34:57 -0700 I cited these Mozilla bug reports to Ollie over IRC: https://bugzilla.mozilla.org/show_bug.cgi?id=61911 https://bugzilla.mozilla.org/show_bug.cgi?id=289933 We fixed the higher-numbered one first, making typeof /a/ == "function". But then we retreated in 61911 due to complaints and (I seem to recall; it's hard to find evidence at the moment) real web compatibility problems. The complaints weren't all from spec-purists who did not like the extension in SpiderMonkey that allows /a/(s) as shorthand for /a/.exec(s). I remember more than a few places where real code was flummoxed by typeof /a/ == "function". This confusing result broke code, whether or not such code expected (this would have been Mozilla-specific code, originally) to be able to call a regexp as shorthand for exec'ing it. Anyway, we threw in the towel with the resolution of 61911. The only further retreat for us is to remove callability, but that may be hard. We may be stuck. We can't easily go back to typeof /a/ == "function", in any event. /be 139909 22 brendan 2009-08-13 10:16:38 -0700 I've re-raised this issue (it has been beaten around before) on es-discuss: https://mail.mozilla.org/pipermail/es-discuss/2009-August/009718.html /be 139938 23 oliver 2009-08-13 11:13:13 -0700 > > and regexp instances have the type "function". > > I think this is the crux of the issue. I know that webkit gives typeof /a/ === > 'function', but I don't understand why. The spec does not say anywhere that a > RegExp defines the internal property [[Call]]. > > > This is correct > > behaviour, per ES5 (from ES262, v5, 11.4.3) > > Object (native and doesn‘t implement [[Call]]) -> "object" > > Object (native or host and implements [[Call]]) -> "function" > > > > Exactly. So, wouldn't RegExp's fall into the first category? Yes, they can be > treated as functions, but that's a particular vendor extension, it's not how > RegExp instances are specified to behave. > > > IsCallable is defined in section 9.11: > > If the argument object has an [[Call]] internal method, then return true, > > otherwise > > return false. > > Right, and again, as per the spec, a RegExp does not have a [[Call]] internal > method. And you can take that up with mozilla who decided to give RegExp are If an object can be called it is by definition callable. To be called an object must provide [[Call]] -- if you look at section 11.2.3 you will see that a function call will throw an exception if IsCallable(func) returns false. Therefore by definition IsCallable must be true. > > > > > In other words, a RegExp instance has [[Call]] so typeof should be "function", > > and [[IsCallable]] is true. > > > > I think we forked back at /a/('a') implying that at a specification level, > [[Call]] is defined for RegExp's. Mozilla extended the spec by saying RegExps were callable, thus forcing us to implement this extension or be broken. [[Call]] is defined on on RegExp as an extension, but that does not make it not present. > Well, as I said above, as far as I can tell, the spec says that RegExp is not > callable, in the sense that the internal [[Call]] property is not defined, > IsCallable will return false and thus at the language level, typeof should > return 'object', and stringify should not ignore it. [[Call]] is defined, IsCallable is true, typeof is function, and serialisation should skip it. If you want to argue this more, please provide a logical explanation beyond "firefox violates spec here, so should you" Once again, the fact that /a/("a") does not throw an exception demonstrates that IsCallable(/a/) must be true in firefox 139950 24 brendan 2009-08-13 11:40:16 -0700 Ollie, could you point me to bugs or URLs showing where you had to follow the SpiderMonkey extension of callable regexps "or be broken"? Thanks, /be 34637 2009-08-11 21:43:54 -0700 2009-08-11 22:54:33 -0700 Patch v1 bug-28117-20090811214353.patch text/plain 6005 oliver ZGlmZiAtLWdpdCBhL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZyBiL0phdmFTY3JpcHRDb3JlL0No YW5nZUxvZwppbmRleCA5NjJlNDZlLi5mM2I2N2I4IDEwMDY0NAotLS0gYS9KYXZhU2NyaXB0Q29y ZS9DaGFuZ2VMb2cKKysrIGIvSmF2YVNjcmlwdENvcmUvQ2hhbmdlTG9nCkBAIC0xLDUgKzEsMTgg QEAKIDIwMDktMDgtMTEgIE9saXZlciBIdW50ICA8b2xpdmVyQGFwcGxlLmNvbT4KIAorICAgICAg ICBSZXZpZXdlZCBieSBOT0JPRFkoT09QUykuCisKKyAgICAgICAgTmF0aXZlIEpTT04uc3RyaW5n aWZ5IGRvZXMgbm90IG9taXQgZnVuY3Rpb25zCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQu b3JnL3Nob3dfYnVnLmNnaT9pZD0yODExNworCisgICAgICAgIE9iamVjdHMgdGhhdCBhcmUgY2Fs bGFibGUgc2hvdWxkIGJlIHRyZWF0ZWQgYXMgdW5kZWZpbmVkIHdoZW4KKyAgICAgICAgc2VyaWFs aXNpbmcgdG8gSlNPTi4KKworICAgICAgICAqIHJ1bnRpbWUvSlNPTk9iamVjdC5jcHA6CisgICAg ICAgIChKU0M6OlN0cmluZ2lmaWVyOjphcHBlbmRTdHJpbmdpZmllZFZhbHVlKToKKworMjAwOS0w OC0xMSAgT2xpdmVyIEh1bnQgIDxvbGl2ZXJAYXBwbGUuY29tPgorCiAgICAgICAgIFJldmlld2Vk IGJ5IEdlb2ZmIEdhcmVuLgogCiAgICAgICAgIFJFR1JFU1NJT046IEhhbmcvY3Jhc2ggaW4gQnl0 ZWNvZGVHZW5lcmF0b3I6OmNvbnN0UmVnaXN0ZXJGb3IgbG9hZGluZyBzaW1wbGUgcGFnZQpkaWZm IC0tZ2l0IGEvSmF2YVNjcmlwdENvcmUvcnVudGltZS9KU09OT2JqZWN0LmNwcCBiL0phdmFTY3Jp cHRDb3JlL3J1bnRpbWUvSlNPTk9iamVjdC5jcHAKaW5kZXggZDY0MzgwOC4uZmVkOWZjMyAxMDA2 NDQKLS0tIGEvSmF2YVNjcmlwdENvcmUvcnVudGltZS9KU09OT2JqZWN0LmNwcAorKysgYi9KYXZh U2NyaXB0Q29yZS9ydW50aW1lL0pTT05PYmplY3QuY3BwCkBAIC0zODEsNiArMzgxLDE1IEBAIFN0 cmluZ2lmaWVyOjpTdHJpbmdpZnlSZXN1bHQgU3RyaW5naWZpZXI6OmFwcGVuZFN0cmluZ2lmaWVk VmFsdWUoU3RyaW5nQnVpbGRlciYKIAogICAgIEpTT2JqZWN0KiBvYmplY3QgPSBhc09iamVjdCh2 YWx1ZSk7CiAKKyAgICBDYWxsRGF0YSBjYWxsRGF0YTsKKyAgICBpZiAob2JqZWN0LT5nZXRDYWxs RGF0YShjYWxsRGF0YSkgIT0gQ2FsbFR5cGVOb25lKSB7CisgICAgICAgIGlmIChob2xkZXItPmlu aGVyaXRzKCZKU0FycmF5OjppbmZvKSkgeworICAgICAgICAgICAgYnVpbGRlci5hcHBlbmQoIm51 bGwiKTsKKyAgICAgICAgICAgIHJldHVybiBTdHJpbmdpZnlTdWNjZWVkZWQ7CisgICAgICAgIH0K KyAgICAgICAgcmV0dXJuIFN0cmluZ2lmeUZhaWxlZER1ZVRvVW5kZWZpbmVkVmFsdWU7CisgICAg fQorCiAgICAgLy8gSGFuZGxlIGN5Y2xlIGRldGVjdGlvbiwgYW5kIHB1dCB0aGUgaG9sZGVyIG9u IHRoZSBzdGFjay4KICAgICBpZiAoIW1faG9sZGVyQ3ljbGVEZXRlY3Rvci5hZGQob2JqZWN0KS5z ZWNvbmQpIHsKICAgICAgICAgdGhyb3dFcnJvcihtX2V4ZWMsIFR5cGVFcnJvciwgIkpTT04uc3Ry aW5naWZ5IGNhbm5vdCBzZXJpYWxpemUgY3ljbGljIHN0cnVjdHVyZXMuIik7CmRpZmYgLS1naXQg YS9MYXlvdXRUZXN0cy9DaGFuZ2VMb2cgYi9MYXlvdXRUZXN0cy9DaGFuZ2VMb2cKaW5kZXggMWM2 MzcyMS4uMGJmNTAyMCAxMDA2NDQKLS0tIGEvTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCisrKyBiL0xh eW91dFRlc3RzL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE4IEBACisyMDA5LTA4LTExICBPbGl2ZXIg SHVudCAgPG9saXZlckBhcHBsZS5jb20+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChP T1BTISkuCisKKyAgICAgICAgTmF0aXZlIEpTT04uc3RyaW5naWZ5IGRvZXMgbm90IG9taXQgZnVu Y3Rpb25zCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0y ODExNworCisgICAgICAgIFRlc3Qgc2VyaWFsaXNhdGlvbiBvZiBmdW5jdGlvbiBvYmplY3RzLgor CisgICAgICAgICogZmFzdC9qcy9KU09OLXN0cmluZ2lmeS1leHBlY3RlZC50eHQ6CisgICAgICAg ICogZmFzdC9qcy9KU09OLXN0cmluZ2lmeS1yZXBsYWNlci1leHBlY3RlZC50eHQ6CisgICAgICAg ICogZmFzdC9qcy9yZXNvdXJjZXMvSlNPTi1zdHJpbmdpZnktcmVwbGFjZXIuanM6CisgICAgICAg ICogZmFzdC9qcy9yZXNvdXJjZXMvSlNPTi1zdHJpbmdpZnkuanM6CisgICAgICAgIChjcmVhdGVU ZXN0cy5yZXN1bHQucHVzaC4pOgorCiAyMDA5LTA4LTExICBCcmFkeSBFaWRzb24gIDxiZWlkc29u QGFwcGxlLmNvbT4KIAogICAgICAgICBSdWJiZXJzdGFtcGVkIGJ5IE1hcmsgUm93ZS4KZGlmZiAt LWdpdCBhL0xheW91dFRlc3RzL2Zhc3QvanMvSlNPTi1zdHJpbmdpZnktZXhwZWN0ZWQudHh0IGIv TGF5b3V0VGVzdHMvZmFzdC9qcy9KU09OLXN0cmluZ2lmeS1leHBlY3RlZC50eHQKaW5kZXggMDA0 YTAxMS4uMTFlZjdiOCAxMDA2NDQKLS0tIGEvTGF5b3V0VGVzdHMvZmFzdC9qcy9KU09OLXN0cmlu Z2lmeS1leHBlY3RlZC50eHQKKysrIGIvTGF5b3V0VGVzdHMvZmFzdC9qcy9KU09OLXN0cmluZ2lm eS1leHBlY3RlZC50eHQKQEAgLTM1Miw2ICszNTIsMTQgQEAgZnVuY3Rpb24gKGpzb25PYmplY3Qp IHsKICAgICB9CiBQQVNTIHRlc3RzW2ldKG5hdGl2ZUpTT04pIGlzIHRlc3RzW2ldKEpTT04pCiBm dW5jdGlvbiAoanNvbk9iamVjdCkgeworICAgICAgICByZXR1cm4ganNvbk9iamVjdC5zdHJpbmdp Znkoe2E6e3RvSlNPTjpmdW5jdGlvbigpeyByZXR1cm4gZnVuY3Rpb24oKXt9OyB9fX0pOworICAg IH0KK1BBU1MgdGVzdHNbaV0obmF0aXZlSlNPTikgaXMgdGVzdHNbaV0oSlNPTikKK2Z1bmN0aW9u IChqc29uT2JqZWN0KSB7CisgICAgICAgIHJldHVybiBqc29uT2JqZWN0LnN0cmluZ2lmeSh7YTpm dW5jdGlvbigpe319KTsKKyAgICB9CitQQVNTIHRlc3RzW2ldKG5hdGl2ZUpTT04pIGlzIHRlc3Rz W2ldKEpTT04pCitmdW5jdGlvbiAoanNvbk9iamVjdCkgewogICAgICAgICB2YXIgZGVlcE9iamVj dCA9IHt9OwogICAgICAgICBmb3IgKHZhciBpID0gMDsgaSA8IDIwNDg7IGkrKykKICAgICAgICAg ICAgIGRlZXBPYmplY3QgPSB7bmV4dDpkZWVwT2JqZWN0fTsKZGlmZiAtLWdpdCBhL0xheW91dFRl c3RzL2Zhc3QvanMvSlNPTi1zdHJpbmdpZnktcmVwbGFjZXItZXhwZWN0ZWQudHh0IGIvTGF5b3V0 VGVzdHMvZmFzdC9qcy9KU09OLXN0cmluZ2lmeS1yZXBsYWNlci1leHBlY3RlZC50eHQKaW5kZXgg OGYyYjhmMS4uYTA1ZTZkOSAxMDA2NDQKLS0tIGEvTGF5b3V0VGVzdHMvZmFzdC9qcy9KU09OLXN0 cmluZ2lmeS1yZXBsYWNlci1leHBlY3RlZC50eHQKKysrIGIvTGF5b3V0VGVzdHMvZmFzdC9qcy9K U09OLXN0cmluZ2lmeS1yZXBsYWNlci1leHBlY3RlZC50eHQKQEAgLTExLDYgKzExLDggQEAgUEFT UyBKU09OLnN0cmluZ2lmeShvYmplY3QsIHJldHVybkFycmF5Rm9yMSkgaXMgJ3siMCI6MCwiMSI6 W10sIjIiOjJ9JwogUEFTUyBKU09OLnN0cmluZ2lmeShhcnJheSwgcmV0dXJuQXJyYXlGb3IxKSBp cyAnWzAsW10sMixudWxsXScKIFBBU1MgSlNPTi5zdHJpbmdpZnkob2JqZWN0LCByZXR1cm5VbmRl ZmluZWRGb3IxKSBpcyAneyIwIjowLCIyIjoyfScKIFBBU1MgSlNPTi5zdHJpbmdpZnkoYXJyYXks IHJldHVyblVuZGVmaW5lZEZvcjEpIGlzICdbMCxudWxsLDIsbnVsbF0nCitQQVNTIEpTT04uc3Ry aW5naWZ5KG9iamVjdCwgcmV0dXJuRnVuY3Rpb25Gb3IxKSBpcyAneyIwIjowLCIyIjoyfScKK1BB U1MgSlNPTi5zdHJpbmdpZnkoYXJyYXksIHJldHVybkZ1bmN0aW9uRm9yMSkgaXMgJ1swLG51bGws MixudWxsXScKIFBBU1MgSlNPTi5zdHJpbmdpZnkob2JqZWN0LCByZXR1cm5OdWxsRm9yMSkgaXMg J3siMCI6MCwiMSI6bnVsbCwiMiI6Mn0nCiBQQVNTIEpTT04uc3RyaW5naWZ5KGFycmF5LCByZXR1 cm5OdWxsRm9yMSkgaXMgJ1swLG51bGwsMixudWxsXScKIFBBU1MgSlNPTi5zdHJpbmdpZnkob2Jq ZWN0LCByZXR1cm5TdHJpbmdGb3JVbmRlZmluZWQpIGlzICd7IjAiOjAsIjEiOjEsIjIiOjIsIjMi OiJ1bmRlZmluZWQgdmFsdWUifScKZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL2Zhc3QvanMvcmVz b3VyY2VzL0pTT04tc3RyaW5naWZ5LXJlcGxhY2VyLmpzIGIvTGF5b3V0VGVzdHMvZmFzdC9qcy9y ZXNvdXJjZXMvSlNPTi1zdHJpbmdpZnktcmVwbGFjZXIuanMKaW5kZXggMmI1Yzg3Mi4uMGZkMTc1 MyAxMDA2NDQKLS0tIGEvTGF5b3V0VGVzdHMvZmFzdC9qcy9yZXNvdXJjZXMvSlNPTi1zdHJpbmdp ZnktcmVwbGFjZXIuanMKKysrIGIvTGF5b3V0VGVzdHMvZmFzdC9qcy9yZXNvdXJjZXMvSlNPTi1z dHJpbmdpZnktcmVwbGFjZXIuanMKQEAgLTMzLDYgKzMzLDExIEBAIGZ1bmN0aW9uIHJldHVybkN5 Y2xlQXJyYXlGb3IxKGssIHYpIHsKICAgICAgICAgcmV0dXJuIGFycmF5OwogICAgIHJldHVybiB2 OwogfQorZnVuY3Rpb24gcmV0dXJuRnVuY3Rpb25Gb3IxKGssIHYpIHsKKyAgICBpZiAoayA9PSAi MSIpCisgICAgICAgIHJldHVybiBmdW5jdGlvbigpe307CisgICAgcmV0dXJuIHY7Cit9CiBmdW5j dGlvbiByZXR1cm5TdHJpbmdGb3JVbmRlZmluZWQoaywgdikgewogICAgIGlmICh2ID09PSB1bmRl ZmluZWQpCiAgICAgICAgIHJldHVybiAidW5kZWZpbmVkIHZhbHVlIjsKQEAgLTUxLDYgKzU2LDkg QEAgc2hvdWxkQmUoIkpTT04uc3RyaW5naWZ5KGFycmF5LCByZXR1cm5BcnJheUZvcjEpIiwgJ1wn WzAsW10sMixudWxsXVwnJyk7CiBzaG91bGRCZSgiSlNPTi5zdHJpbmdpZnkob2JqZWN0LCByZXR1 cm5VbmRlZmluZWRGb3IxKSIsICdcJ3siMCI6MCwiMiI6Mn1cJycpOwogc2hvdWxkQmUoIkpTT04u c3RyaW5naWZ5KGFycmF5LCByZXR1cm5VbmRlZmluZWRGb3IxKSIsICdcJ1swLG51bGwsMixudWxs XVwnJyk7CiAKK3Nob3VsZEJlKCJKU09OLnN0cmluZ2lmeShvYmplY3QsIHJldHVybkZ1bmN0aW9u Rm9yMSkiLCAnXCd7IjAiOjAsIjIiOjJ9XCcnKTsKK3Nob3VsZEJlKCJKU09OLnN0cmluZ2lmeShh cnJheSwgcmV0dXJuRnVuY3Rpb25Gb3IxKSIsICdcJ1swLG51bGwsMixudWxsXVwnJyk7CisKIHNo b3VsZEJlKCJKU09OLnN0cmluZ2lmeShvYmplY3QsIHJldHVybk51bGxGb3IxKSIsICdcJ3siMCI6 MCwiMSI6bnVsbCwiMiI6Mn1cJycpOwogc2hvdWxkQmUoIkpTT04uc3RyaW5naWZ5KGFycmF5LCBy ZXR1cm5OdWxsRm9yMSkiLCAnXCdbMCxudWxsLDIsbnVsbF1cJycpOwogCmRpZmYgLS1naXQgYS9M YXlvdXRUZXN0cy9mYXN0L2pzL3Jlc291cmNlcy9KU09OLXN0cmluZ2lmeS5qcyBiL0xheW91dFRl c3RzL2Zhc3QvanMvcmVzb3VyY2VzL0pTT04tc3RyaW5naWZ5LmpzCmluZGV4IGU0MDIzMTMuLmYw MjRiN2UgMTAwNjQ0Ci0tLSBhL0xheW91dFRlc3RzL2Zhc3QvanMvcmVzb3VyY2VzL0pTT04tc3Ry aW5naWZ5LmpzCisrKyBiL0xheW91dFRlc3RzL2Zhc3QvanMvcmVzb3VyY2VzL0pTT04tc3RyaW5n aWZ5LmpzCkBAIC0zMTYsNiArMzE2LDEyIEBAIGZ1bmN0aW9uIGNyZWF0ZVRlc3RzKCkgewogICAg ICAgICByZXR1cm4ganNvbk9iamVjdC5zdHJpbmdpZnkoe2E6e3RvSlNPTjpmdW5jdGlvbigpeyBy ZXR1cm4gbnVsbDsgfX19KTsKICAgICB9KTsKICAgICByZXN1bHQucHVzaChmdW5jdGlvbihqc29u T2JqZWN0KXsKKyAgICAgICAgcmV0dXJuIGpzb25PYmplY3Quc3RyaW5naWZ5KHthOnt0b0pTT046 ZnVuY3Rpb24oKXsgcmV0dXJuIGZ1bmN0aW9uKCl7fTsgfX19KTsKKyAgICB9KTsKKyAgICByZXN1 bHQucHVzaChmdW5jdGlvbihqc29uT2JqZWN0KXsKKyAgICAgICAgcmV0dXJuIGpzb25PYmplY3Qu c3RyaW5naWZ5KHthOmZ1bmN0aW9uKCl7fX0pOworICAgIH0pOworICAgIHJlc3VsdC5wdXNoKGZ1 bmN0aW9uKGpzb25PYmplY3QpewogICAgICAgICB2YXIgZGVlcE9iamVjdCA9IHt9OwogICAgICAg ICBmb3IgKHZhciBpID0gMDsgaSA8IDIwNDg7IGkrKykKICAgICAgICAgICAgIGRlZXBPYmplY3Qg PSB7bmV4dDpkZWVwT2JqZWN0fTs=