Fix compilation with namespaced Qt

This also moves the extern "C" symbols back into the QV4 namespace

Change-Id: Id6d137df8610010588554bf0660228b357477823
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Prospective CI system build fix for Ubuntu 10.04's gcc

Change-Id: I4293c3a75e6a98cafd8f41a68012102628416610
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Various build fixes for Windows:

* Fix processor #defines in stack trace generation code
* Fix return type of doEdgeSplitting. It doesn't actually return anything.
* Work around internal compiler error in the array construction in qquickworkerscript.cpp

Change-Id: I8fac4bc2e8ca7447f4eeff260d8502d70ff6faf6
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Fix build with msvc2010 in 32-bit mode

It cannot map a function pointer that returns a structure that isn't known
at declaration time.

Done with Lars.

Change-Id: I02a241695a6f6a94883507eb2c4988852cc9b912
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Disable the JIT on Windows/AMD64 as well as on iOS

Change-Id: I7402981caa2f73fd0712975e657488a4065f403f
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Fix crashes with MSVC on x86

When returning a struct like QV4::Value from a function, the compiler can
either place the return value into the stack by expecting the caller
to provide a hidden first argument (pointer to where to store the value)
or pass it in eax:edx. The choice of which approach to pick depends on
whether the type is known at function declaration time. In this case we
had a mismatch where qv4serialize.cpp had a function that returned a value
and it is implemented by calling another function that would return the value.
QV4::Value was forward-declared, and so when compiling the function, the
compiler would assume that the caller provided an invisible first argument
for return value storage. The caller (in qquickworkerscript.cpp) however
had fully visibility of QV4::Value at call time and therefore assumed that
the value is returned in eax:edx. This mismatch caused naturally all sorts
of funny crashes.

The approach chosen is to eliminate any forward declarations of QV4::Value
and instead include the definition where appropriate.

Change-Id: I33303d86964239d3be30d1096806c605cddb7bbc
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Fix crash in qqmlecmascript::sequenceSort with MSVC in debug builds

ArrayPrototype.sort allows specifying a compare function implemented in JS,
which we "wrap" and then pass on to std::sort. std::sort with MSVC has
an assertion verifying that the less-than compare function provided is
perfectly consistent in its return values. We don't want JS to easily crash
the entire application and therefore resort to qSort().

Change-Id: Id2c758a7d2bee60f31a7a3971172bca9b3c69af6
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Fix build with MingW

We can use the same win32 functions here to get the stack base address.

Change-Id: I7f26434b2c479772eaee94b8a9f7e1eba7f0721f
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Fix failing assertion with MSVC in debug builds in various tests

We re-implemented Vector::begin() and end() by means of dereferencing the return
value from std::begin() and then taking the address of it. That causes a failing
assertion in MSVC's STL (rightly so!). We did this only to avoid modifying
the original YarrJIT.cpp code.

This patch instead simplifies our Vector.h stub again and just fixes the two
small occurrences in YarrJIT.cpp where it expects vector->begin() to return a
pointer instead of an iterator.

Change-Id: I2ad137be91ea969ccb310333dffa8d98e5825f8f
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Fix tst_QJSValue::engineDeleted with MSVC

Don't return void in a non-void function :)

Change-Id: I467347a9471655d3c3472dbe3690e9d26cad7e46
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Fix module name (QtQml) in the license header under src/3rdparty

Also updating the copyright year to 2013

Change-Id: I743d93d13d1841e13600f7353c4fe3e05bbd7c32
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>