Also: Change signature of these functions and methods to all have the same arguments in the same order: (cx, obj, id, v, receiver). Also change v from MutableHandleValue to HandleValue.
There is no change in behavior.
In fact the new error message `JSMSG_SET_NON_OBJECT_RECEIVER` is
impossible to trigger from scripts for now, I think (after re-reading
the whole patch with this in mind). JS_ForwardSetPropertyTo is the only
way to get a non-object receiver into the engine, but no caller
currently does so.
We're installing new pipes here, and they should work, but for now it's
the same cold water flowing through as before. Actually hooking up the
hot water is left for another bug (one with tests, not to put too fine a
point on it).
Notes:
* InvokeGetterOrSetter had to be split into two functions:
InvokeGetter takes a MutableHandleValue out-param,
InvokeSetter a HandleValue in-param.
* Watchpoints can still tamper with values being assigned. So can
JSSetterOps. I'm pleased we can support this craziness in a way that
doesn't have to spread via the type system to encompass the entire
codebase.
* Change in GlobalObject::setIntrinsicValue is not really a change.
Yes, it asserted before, but an exception thrown during self-hosting
initialization is not going to go unnoticed either.
* Since the receiver argument to js::SetProperty() is at the end now, it
makes sense for it to be optional. Some callers look nicer.
--HG--
extra : rebase_source : 68cd15627a62728061e663706cb1ff8c7bb292a0
Add an ObjectOpResult out-param for DefineProperty functions everywhere. We leave a few js::DefineProperty() convenience functions with no *result out-param. These have strict behavior: that is, they automatically check the result and throw if it is false. In bug 1125624 these strict signatures may end up being called DefinePropertyOrThrow, as that is what the spec calls it.
--HG--
extra : rebase_source : 36439a8fa433c453f63b02c93fceaf0d8b9e9626
Also renamed in this patch:
ENUMERATE_IF_DEFINED -> ADD_KEYS_IF_DEFINED
XrayEnumerateAttributesOrMethods -> XrayAttributeOrMethodKeys
XrayEnumerateNativeProperties -> XrayOwnNativePropertyKeys
XrayEnumerateProperties -> XrayOwnPropertyKeys
WrapperOwner::getPropertyNames -> getPropertyKeys
These make sense because JSITER_* flags are involved; the functions in
question are not for finding enumerable properties only.
--HG--
extra : rebase_source : 35fb0fa3c8f3d7bc952409ea8c584e58f3c1d78f
Apply the following script
sed -i '
/JS_ASSERT(/ {
s/JS_ASSERT(/MOZ_ASSERT(/;
:b;
s/ \\$/\\/;
/;/ { p; d; };
n;
s/^/ /;
b b;
};
s/JS_ASSERT (/MOZ_ASSERT(/;
'
Except where the JS_ASSERT macro does not end with a semi-colon, where empty
lines are in the middle of the macro, and where the backslahes are always the
same-length after the expression.
While adding the CPOW flag for xray waivers, I discovered a bunch of
inconsistency and sloppiness with respect to our handling of object ids,
and a general lack of clarity about when the id included flags or not. Given
the fact that I'm removing static callability for CPOWs, we _could_ just get
rid of the flags, and store the xray waiver state on the answer-side only. But
I eventually decided that these kinds of flags (which are accessible to both
the Answer _and_ the Owner) had enough potential utility that they were worth
cleaning up.
It's worth noting that that utility comes with the large caveat that the flags
can't be trusted for security-sensitive decisions (at least in the parent->child
case), since they could be forged by a compromised child.
