SpiderMonkey ESR31 upgrade

[Yves]

Now that the ESR24 upgrade is done (#1886), I've started working on the ESR31 upgrade. You can test the current WIP version on my ​github repository (ESR31 branch). Read the readme there for additional information.

Depends on

#2669

When updating, don't forget to also fix #2684 and #1374.

[Niek]

I thought SpiderMonkey 3.1 will be released in July 2014?

"The next release will be SpiderMonkey 31, around July 2014." ​https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey

[Erik Johansson]

The better to start on the upgrade now rather than wait until after it's been released ;)

[Niek]

But in that case you take the risk that you need to change drastically if the guys @Mozilla do so.

[Yves]

There are two big advantages when starting with the upgrade now.

1. If we find problems that need to be fixed in SpiderMonkey, we can still get these changes in before the next release. The Firefox (and SpiderMonkey) development starts in the mozilla central repository where big features get integrated. After that it moves to the "Aurora" stage where usually only important bugfixes get applied. This transition will be around the 28th of April, so it's good to start now.
2. When updating around once a week, it's easier to figure out the reason if a change breaks something. You can check last week's commit logs or ask people what happened last week. That's harder if you have to search in a period of multiple months.

Sometimes there are bugs and it can take a while to figure out it's not a problem in our code, but the advantages outweight this problem.

[Yves]

C++11 support is required to use SpiderMonkey 31. I have checked today if patching the headers would be an alternative to avoid that, but it would result in too deep changes. I've replaced all the static_asserts, but then didn't investigate any further when I figured out that the headers also use move constructors. I've created ticket #2669 for the C++11 migration.

[Yves]

In 15516:

Changes our JSNative functions to use JS::CallReceiver/JS::CallArgs.

This is the new way for working with arguments in JSNative functions. JS_THIS_VALUE, JS_ARGV, JS_SET_RVAL and direct access to vp or argc are deprecated and will probably be removed in future versions of SpiderMonkey.
CallArgs also takes care of proper rooting and you can get the values as Handles or MutableHandles. The interface changes a little bit for ESR 31, but commiting this now still makes it easier and the changes shout be straigtforward (search and replace more or less).

Refs #2462
Refs #2415

[Yves]

In 15517:

Changes FromJSVal to take a JS::HandleValue instead of JS::Value.

JS::HandleValue is basically a wrapper around a JS::Value that is safe for exact stack rooting and moving GC.
I've tried to keep this changeset rather small and isolated and therefore create additional JS::Rooted<T> values at some places where the function should eventually directly take a JS::Handle<T>.
The functions "CallFunction" and "CallFunctionVoid" put their arguments inside a JS::AutoValueVector because this will be passed directly to "CallFunction_" with ESR31.

Refs #2462
Refs #2415

[Yves]

In 15524:

Makes custom JS objects compatible with SpiderMonkey ESR31.

In v24 you called JS_InitClass and passed in a definition of JSNative functions. Later you could call JS_NewObject with this class and the object would get a prototype with the specified JSNative functions.
In ESR31 you now have to explicitly store the prototype object returned by JS_InitClass and pass it as prototype argument to JS_NewObject to achieve the same.
This change modifies our existing ScriptInterface implementation for custom object types a bit and uses it at places where the JSAPI was used directly before.

Refs #2462

[Yves]

In 15534:

Changes ToJSVal to take JS::MutableHandleValue instead of JS::Value&.

JS::MutableHandleValue is similar to JS::HandleValue, but the whole JS::Value it points to can be replaced.
This change is needed for support of exact stack rooting and moving GC.
Contains a few other trivial API adjustments and style improvements too.

Refs #2462
Refs #2415

[Yves]

In 15541:

Implements CallFunction with JS::MutableHandle<T> return type.

Changes the CallFunction implementation to use macros because otherwise we'd have to write twice as many functions manually.
Adapts GetSavedGameData to use the new function template. Additional callers will be changed in future commits.

Refs #2415
Refs #2462

[Yves]

In 15542:

Adds support for passing JS::HandleValue to SetProperty and CallFunctionVoid without using ugly casing.

Also includes one little "demo-usecase", but additional code will be changed to use that in future commits.

Refs #2415
Refs #2462

[Yves]

In 15568:

Quite a lot of stack rooting related changes.

Changes GetProperty, SetProperty and HasProperty and a few other functions to take handles. The conversions to CScriptVal or CScriptValRooted at some places should be removed in the future. I've done that to avoid an even larger patch.

Refs #2415
Refs #2462

[Yves]

In 15592:

More exact stack rooting (CallFunction object).

Changes CallFunction and CallFunctionVoid to use a HandleValue as object parameter. Also changes some JS serialization/deserialization functions to only support the JSAPI rooted types (drop support for CScriptVal and CScriptValRooted there). Some other functions got changed too because they were closely related.

Refs #2415
Refs #2462

[Yves]

In 15597:

Exact stack rooting for structured cloning functions.

Refs #2415
Refs #2462

[Yves]

In 15600:

Removes an unused codepath for AI deserialization and related ScriptInterface code.

It might actually be needed again in the future, but I think even then it would be easier to rewrite it than having to update the code in the meantime.

Refs #2462

[Yves]

In 15601:

Exact rooting for CallConstructor.

Refs #2415
Refs #2462

[Yves]

In 15603:

Exact stack rooting for JSON related ScriptInterface functions.

Refs #2415
Refs #2462

[Yves]

In 15605:

Exact stack rooting for ScriptInterface::ToString.

I had to change a few other functions to take JS::MutableHandleValue because JS::Stringify takes a JS::MutableHandleValue as input parameter. That seems a bit strange because it should not change that value.
I assume it has historical reasons.

Refs #2415
Refs #2462

[Yves]

In 15623:

Exact stack rooting for IGUIObject.

Refs #2415
Refs #2462

[Yves]

In 15944:

Exact stack rooting for CParamNode

Refs #2415
Refs #2462

[Yves]

In 15946:

Replace CScriptValRooted with JS::Heap<T> and custom tracer for CNetClient

Refs #2462

[leper]

#1374 can be considered fixed with SM29+.