| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ES6 spec specifies ReturnIfAbrupt between each of these steps,
covering cases where for instance some strange person passes an Object
to the setYear function, with a valueOf that throws.
This improves our pass rate on built-ins/Date/prototype on the ES6 tests
significantly.
Before:
=== Summary ===
- Ran 1144 tests
- Passed 1076 tests (94.1%)
- Failed 68 tests (5.9%)
After:
=== Summary ===
- Ran 1144 tests
- Passed 1110 tests (97.0%)
- Failed 34 tests (3.0%)
Change-Id: I616d5727eb6ae197699aa4021631f17c7346de27
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Don't return -0 from TimeClip (20.3.1.15, 1)
* Mark length configurable (19.2.4.1)
* toUTCString and toGMTString must be the the same object (B.2.4.3)
Brings us a bit closer to passing tests. Still some failures in other
areas.
Change-Id: I905216b8653ac0b33cb27e6b773616521fbb5daa
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
| |
Change-Id: I2cd1df437d91918001beed8dfe92d553b3bb377f
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
| |
It's enough to just call stringValue(), as that already
does the isString() check.
Change-Id: I7be0e643a7975c0704b4c9c43b337deb8db9fce0
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
| |
Change-Id: Iad64dd2c330ca85a28f8f5c776b0ede623203558
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
GCC6 might dead-store-eliminate out our secret write to Base::mmdata,
because it expects all memory content to be "undefined" before
constructor calls. Clang might take the same approach if the constructor
of Heap::Object is removed.
By making these structs trivial, it also makes them memcpy-able.
Change-Id: I055b2ad28311b997fbe059849ebda4d5894eaa9b
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By specification, date conversion functions for dates before the epoch
are not DST corrected. We converted QTime to a QDateTime where we set
the date part to Jan. 1, 1970, and then convert that to msecs since the
epoch UTC. For places on Earth where they had DST on that day (e.g.
Hobart in Australia), strange things happen: conversion from a QTime to
DateObject will use DST (because it's after the epoch in local time),
but conversions from DateObject to QTime won't use the DST because it's
before the epoch (in UTC).
Now as everyone knows, a 24-hour clock time has no meaning without a
date, only "elapsed time" has. But users still expect to be able to pass
QTime to QML/JS. So, we do the conversion on day 0 of month 0 of year 0,
and all of it in local time. This gives a stable conversion in both
directions, and the values in both C++ and QML/JS are the same for any
timezone (with or without DST) on this planet.
Task-number: QTBUG-54378
Change-Id: I892e16a93f015e92d311c6cae3ae7768b7373f6a
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... or with QL1C in such cases:
- if there is overloaded function
- in QStringBuilder expressions
Saves ~1.5 KB in text size.
Build config: ubuntu 16.04 x64, gcc 5.3
Change-Id: Icc0789f1c244ce20a3182494b0c7f35c9d77e41d
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The implementation of many (or all) runtime functions consist of first
creating a QV4::Scope, which saves and restores the JS stack pointer.
It also prevents tail-calls because of that restoring behavior. In many
cases it suffices to do that at the entry-point of the runtime.
The return value of a JS function call is now also stored in the scope.
Previously, all return values were stored in a ScopedValue, got loaded
on return, and immediately stored in another ScopedValue in the caller.
This resulted in a lot of stores, where now there is only one store
needed, and no extra ScopedValue for every function.
Change-Id: I13d80fc0ce72c5702ef1536d41d12f710c5914fa
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/qml/jsapi/qjsengine.cpp
src/qml/qml/qqmlengine_p.h
src/quick/items/qquickanchors.cpp
src/quick/items/qquickanimatedimage_p_p.h
src/quick/items/qquickitem_p.h
tests/auto/qml/qqmlecmascript/testtypes.h
tests/auto/qml/qqmlecmascript/tst_qqmlecmascript.cpp
tests/benchmarks/qml/creation/tst_creation.cpp
Change-Id: I65861e32f16e8a04c7090a90231627e1ebf6ba6f
|
| |
| |
| |
| |
| |
| |
| | |
The latter can be inlined.
Change-Id: I57747b84889390839a17faa1df6d359210ef4adf
Reviewed-by: Gunnar Sletta <gunnar@sletta.org>
|
|\ \
| |/
| |
| | |
Change-Id: I60b8a701b6d90f8572143cf760873f6b8b453c14
|
| |
| |
| |
| |
| |
| |
| |
| | |
These constexpr functions can be inlined, and the compiler can be a bit
smarter with code generation.
Change-Id: I4ea87c794dd8e375749e18d273d01bb848231113
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
|
|/
|
|
|
|
|
| |
... introduced with e0ea0f6178 in QtBase.
Change-Id: I5b93236a28de237b407a3eaa26078242fa8d58ff
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
| |
From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new LGPL header instead of LGPL21 one
(in those files which will be under LGPL v3)
Change-Id: Ic36f1a0a1436fe6ac6eeca8c2375a79857e9cb12
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
| |
We generally don't want to produce signalling NaNs as those cannot be
used in any further arithmetic operations.
In particular -(qSNaN()) claims it's not a double.
Task-number: QTBUG-49753
Change-Id: I23cec4fec2ddf08c02a7d53db7f3b9ba46b6c288
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
|
|
|
|
|
| |
Change-Id: I0241efe10d115f8e4a646f840e47e220eb6cfc18
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
|
|
|
|
|
| |
Change-Id: Ib55c05f1730b7659e2f6fee7e1fa79c10c759167
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
|
|
|
|
|
|
|
| |
Convert most of the prototype objects in the v4 engine.
Change-Id: I365f290493c20973bc991b6a383649836e42a16a
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
|
|
|
|
|
| |
Change-Id: I6ae05a066d021e81eaed90866e09bf480f5d91d9
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
|
|
|
|
|
|
|
|
| |
This is a cleaner separation and further reduces include dependencies
in the definitions of our basic data structured.
Change-Id: I18aa86cdea0c0dfbc16075d4d617af97e638811e
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
|
|
|
|
|
| |
Change-Id: Ib4858376dc0ec57fa473c80696abc66a570c90ec
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
|
|
|
|
|
|
|
|
| |
Get rid of Value::asObject(), and pass const Managed pointers
into some more vtable methods.
Change-Id: Ia4f427d5fd8868f77b4015d1ce5424d32bfc2115
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
|
|
|
|
|
| |
Change-Id: I71816a784b5175f600c5a870318b16c0d84c42fb
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
|
|\
| |
| |
| | |
Change-Id: I4c338a44c1d64c2d8e637971ab3ec6982c40a685
|
| |
| |
| |
| |
| |
| |
| | |
If you don't include it, it isn't defined...
Change-Id: I1a800c709d3543699131ffff13c388ba652761fc
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Use std::math on floats and doubles, and qMath on qreals, and only
include the math headers actually needed.
Change-Id: I1d511d7b1bac0050eaa947c7baee760b736858bf
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Change-Id: I61120571787870c0ed17066afb31779b1e6e30e9
Reviewed-by: Iikka Eklund <iikka.eklund@theqtcompany.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Simplify some code in BooleanObject
Simplify access to call arguments and thisObject
Change-Id: I2f8e844019bc587385608beb02f05b15f827535c
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
| |
| |
| |
| |
| | |
Change-Id: Icd76d3d03fac2e57530e55f8ec15b97109dcdcbc
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
| |
| |
| |
| |
| | |
Change-Id: I596f14554d81f5e9af9996294d96047f2e810bef
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
The memory manager's allocation methods now set this up correctly
for us :)
Change-Id: I8492bf732df601f95a1a851fb3804127ffc83935
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
| |
| |
| |
| |
| | |
Change-Id: Ia52f0e6db325aab37477d455f163487b319dce29
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
.qmake.conf
src/qml/jsruntime/qv4context_p.h
src/qml/jsruntime/qv4debugging.cpp
src/qml/jsruntime/qv4engine.cpp
src/qml/jsruntime/qv4functionobject_p.h
src/qml/jsruntime/qv4qobjectwrapper.cpp
src/quick/scenegraph/shaders/visualization.frag
tests/auto/qml/qjsengine/tst_qjsengine.cpp
Change-Id: I492e8546c278f80a300a2129e9a29d861e144a30
|
| |
| |
| |
| |
| |
| |
| |
| | |
[ChangeLog][QtQml] Fix JavaScript Date parsing to correctly accept RC2822 dates.
Task-number: QTBUG-38011
Change-Id: Ic7d3f5b8c624d6780d4c3595fd2efe22c427ffd3
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
|
| |
| |
| |
| |
| |
| |
| | |
This is no longer required, and simply uglifies the code
Change-Id: Iba91a1d7735ebe23a43437f137a488423b6eb743
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit f06daaf3d8747c6c0a277bf055c80d8f2e7bcc81.
The only things actually specified by the ECMAScript standard on dates
are:
1. Reparsing a date output from any of the to*String() functions has to
result in the same date representation.
2. The ISO 8601 standard has to be followed for the ISO format.
Currently we clearly don't follow rule 1. Date.parse(d.toString()) will
not yield the same as d.valueOf() for negative dates.
The ISO 8601 standard clearly has a year 0 while common human language
has not. All non ISO date representations are considered
"implementation-dependent" in the ECMAScript standard. We can thus
define the relation between our representations and the ISO standard any
way we like. If we try to match up the dates so that the negative years
look equal in each representation we cannot properly interact with QDate
for dates in the year 0 as that doesn't exist in QDate. We can, however,
choose not to make the dates look equal. That means a date with a
negative year will be "one off" when represented in ISO 8601. "333 BC"
in human language is "-332" in ISO 8601. Our internal representation is
aligned to ISO 8601 and the to*String() methods may output something
else. That means we can easily set the year in ISO 8601 sense from the
Date constructor as well as from setYear() and setFullYear().
This, of course, is somewhat unintuitive and also differs from most
other JavaScript implementations (which don't have to interoperate with
QDate). However, it is still correct.
Change-Id: I5fc26b709a486cb520a075918b184a80bec56c9b
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
| |
| |
| |
| |
| | |
Change-Id: I16b6662a47c682e145d3e2201f9e90f58405a599
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
This is the only way we can support a GC that moves
objects around in memory.
Change-Id: I1d168fae4aa9f575b730e469e762bc5b5549b886
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Avoid the use of Returned<String> for newString and changed the identifier
table to use Heap::String. This required moving some code back into
Heap::String, but that's code that doesn't call back into the GC, so
allocations and therefore future object moves aren't possible.
Change-Id: I1dca3e9c12a9c56f09419af8cc8cba39fe04f720
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
|
| |
| |
| |
| |
| |
| |
| | |
This is safer and cleaner than to use a context pointer.
Change-Id: Id5ef4e6667571897cd029125a0bdc18ce299da6d
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
| |
| |
| |
| |
| | |
Change-Id: Id2092a15c9fb5341d9b5cf4a9ac7a978308e4174
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
| |
| |
| |
| |
| | |
Change-Id: Iadf74f953798c1884e0ec704ccb7c70d971e3273
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
| |
| |
| |
| |
| | |
Change-Id: I9d30081f71b83bc86f5e5714e23396b18c4d54c5
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
The methods don't require a context, and thus shouldn't be
implemented there.
Change-Id: If058e0c5067093a4161f2275ac4288aa2bc500f3
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
|/
|
|
|
| |
Change-Id: Ibb4658576a98b53de2eac2474ce4d5b9eb83b6ae
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
JavaScript knows a year 0. That is correctly translated into QDateTime
terms when creating a Date object, but it's not correctly translated
back when converting the JavaScript date to a string.
Task-number: QTBUG-29491
Change-Id: I46b200a144434187656d08e87f422f97523acd0e
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
|
|
|
|
|
|
|
|
| |
The methods where converting doing a localtime->UTC
conversion even though the input was already in UTC.
Task-number: QTBUG-38448
Change-Id: I4409275fade0dd2a677af2293edc87445f853879
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
|
|
|
|
|
|
|
|
| |
- Renamed LICENSE.LGPL to LICENSE.LGPLv21
- Added LICENSE.LGPLv3 & LICENSE.GPLv2
- Removed LICENSE.GPL
Change-Id: I84a565e2e0caa3b76bf291a7d188a57a4b00e1b0
Reviewed-by: Jani Heikkinen <jani.heikkinen@digia.com>
|
|
|
|
|
| |
Change-Id: I90042037bc0555771bd98233977c7d2b735bb718
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|