If the variant contains a known json type (value, array, object or
document), simply unwrap those. In the case of the json document
wrap the contained object/array into a QJsonValue.
This should be the expected behavior, and makes more sense than
returning a null QJsonValue.
Task-number: QTBUG-41234
Change-Id: Id084fc11220d51aaf78b7694fd0ebef1411f5c51
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When using non latin keys, remove() could cause corruption
of the json object.
Task-number: QTBUG-42270
Change-Id: I7305e57ebb78630a9bf68bc4f831a6d1646abb79
Reviewed-by: Thiago Macieira <thiago.macieira@intel.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.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
Unify the behavior of the different operator<< by always using
QDebugStateSaver (appending an optional space at exit), and making
sure that the space(), nospace() setting isn't 'leaked'.
Change-Id: I38e4f82fa6f7419d8b5edfc4dc37495af497e8ac
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
Add test data to resources.
Change-Id: Ib8a5688e7caab8434b8f0676f53a2a79ec94b264
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@theqtcompany.com>
Adds automatic conversion from QVariants with a QVariantHash to
QJsonValue and explicit methods for conversion between QVariantHash
and QJsonObject.
[ChangeLog][QtCore][QJsonObject] Added conversion to and from QVariantHash
Change-Id: I140ef881463acabaab2648e28209487d8ad18e0d
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
tst_qtjson.cpp(2711) : warning C4566: character represented by universal-character-name '\u2090' cannot be represented in the current code page (1252)
tst_qtjson.cpp(2712) : warning C4566: character represented by universal-character-name '\u2090' cannot be represented in the current code page (1252)
tst_qtjson.cpp(2713) : warning C4566: character represented by universal-character-name '\u2090' cannot be represented in the current code page (1252)
Task-number: QTBUG-41100
Change-Id: I193dc48236bdd3857657a5684178630f0e1dab6d
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
This reverts commit 20cf632ad5. The commit
produced to many problems during statics destruction. For example
causing QtCreator crash (QTBUG-40987).
Change-Id: Ib52f6a449c2d84deab2de792559a6a065ca45e8d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
A well formed JSON document is not allowed to contain
trailing garbage at the end. Don't accept this in the
parser.
Task-number: QTBUG-40062
Change-Id: I0a09dbd099a8c643f58023342546c4e67d026fec
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
The comparison operators between QJsonPrivate::String
and QJsonPrivate::Latin1String weren't all correct, leading
to wrong sorting of keys in QJsonObjects when the keys were
outside of the latin1 range and resulting lookup errors.
Task-number: QTBUG-41100
Change-Id: Idceff615f85d7ab874ad2a8e4a6c1ce8c2aa0f65
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
The iterators for QJsonArray and QJsonObject are currently lacking an
operator-> definition. Unfortunately it is not possible to do in clean
way without redefining either the iterators or QJsonValueRef class.
This patch instead adds two fake pointer classes that are only used
to handle the operator-> return value.
Task-number: QTBUG-29573
Change-Id: Ief785a6afbbedc9e89cf3b6f3958c2c755997a66
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
It allows to create a QJsonObject instance in C++ by using
initializer list of pairs QString QJsonValue, for example:
QJsonObject o = {{"property1", 1}, {"property2", 2}};
[ChangeLog][QtCore][QtJson] QJsonObject now supports
C++11 initializer lists.
Task-number: QTBUG-26606
Change-Id: I67af881e175f427e563e685336c48a5f8466b476
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QJsonValue, while comparing two QJsonArrays, should consult also length
of the arrays, because a different than null base pointer doesn't mean
that an array is not empty.
Change-Id: If76739355a4e74b842e836289565f98d95c006d5
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
QJsonValue, while comparing two QJsonObjects, should consult also length
of the objects, because a different than null base pointer doesn't mean
that an object is not empty.
Change-Id: Ibee1849ef9fed15d32f2c8f2aad9b053846e46b7
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Before this change such code:
QJsonObject o;
o["blah"];
would create property "blah" and assign null value to it, while
this code:
const QJsonObject o;
o["blah"];
would not. The change unifies the confusing behavior. Now reading
a non-existing property, is not causing a property to be added
in any visible way.
Internally QJsonObject stores a special hash of undefined, but
referenced values. Such reference is supposed to not live long,
only to the first compacting or assignment.
Change-Id: Ib022acf74ff49bad88d45d65d7093c4281d468f1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
The operator should always return an undefined values for an empty
object
Change-Id: Ic38f7660d77c64b2d001967bc5109df4185db74a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
It allows to create a QJsonArray instance in C++ by using
a similar expression to JSON. For example:
QJsonArray a = {1, 2, 4};
[ChangeLog][QtCore][QtJson] QJsonArray now supports
C++11 initializer lists.
Task-number: QTBUG-26606
Change-Id: Icc352e518d9649d24176c89e7113d200d5c50b0d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Currently QJsonValue and QJsonValueRef behave differently in
regard to the default values leading to confusion compile errors
depending on which of the two types one is actually using. Before
this change it was possible to write:
QJsonValue value = jsonObject["item"];
QString name = value.toString(QStringLiteral("default"));
but not:
QString name = jsonObject["item"].toString(QStringLiteral("default"));
Change-Id: Id1185acf339aa3a91e97848e85d068f84552df71
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Extending this to stock QNX as well since it is not
BlackBerry 10 specific.
- tst_QNumeric::floatDistance()
- tst_QNumeric::floatDistance_double()
- tst_QtJson::testNumbers_2()
- tst_QtJson::toJsonLargeNumericValues()
- tst_QtJson::parseNumbers()
Task-number: QTBUG-37066
Change-Id: If0e5d4fbefac5e8a0efed8ef8b1b7655ff6e7766
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
- QVariant can store (U)Int, (U)LongLong, Float and Double numbers.
Previously, QJsonValue::fromVariant() converted Floats into Strings
while converting the others to Doubles.
- Add unit tests for QJsonValue::fromVariant()
[ChangeLog][QtCore][JSON] QJsonValue::fromVariant() will now convert
single-precision Floats into Doubles instead of Strings
Change-Id: I457adbe29c37ada611d1c6d711c42866d63d4024
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
These tests seem to fail because denormalized numbers are not
supported on QNX yet, so marking them as expected failures.
- testNumbers_2()
- toJsonLargeNumericValues()
- parseNumbers()
Task-number: QTBUG-37066
Change-Id: Ifec95b936fb70253395dee4d1ca18e85870486a3
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
For convenience, it reads more easily (and is somewhat expected) to
be able to add a string to a QJsonArray like you might with a
QVariantList: QJsonArray() << "string". Previously, QJsonValue provided
a private void* ctor to explicitly deny this case because it would
implicitly convert to a boolean. This ctor provides a const char* ctor
(much like QVariant) that interprets the incoming text as utf8 and
creates a String type QJsonValue.
[ChangeLog][QtCore][QJsonValue] Added constructor to QJsonValue for const char *
Change-Id: Icafa954d3da1fb264f9d0fd7cd1a1d2fbbe15095
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
operators for +, +=, and << were added to QJsonArray to make
it easier to work with, and more closely resemble the Qt
container classes
[ChangeLog][QtCore][QJsonArray] Added convenience methods to QJsonArray for appending QJsonValues
Change-Id: I96e0a43015f7c0f980cbbef7f20bd2085ee04795
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
The encoder is in qjsonwriter.cpp, which requires special handling for
ASCII due to the use of escape sequences. The decoder is in
qjsonparser.cpp, which only scan one character at a time.
As a side-effect, the JSON parser now reports the UTF-8 error in the
first character with error, instead of the last. This is probably what
should have been expected.
Change-Id: I52e5bc30d71466b6a36098b4150c61b2e385d8e9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's unexpected that all messages generated by the stream version
of qDebug and friends have a trailing space. It also makes switching
to categorized logging (which only supports the stream version) difficult,
since all autotests checking for debug output would have to be adapted.
Task-number: QTBUG-15256
Change-Id: I8d627a8379dc273d9689f5611184f03607b73823
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Changed the processing of non-character code handling in the UTF8 codec.
Non-character codes are now accepted in QStrings, QUrls and QJson strings.
Unit tests were adapted accordingly.
For more info about non-character codes,
see: http://www.unicode.org/versions/corrigendum9.html
[ChangeLog][QtCore][QUtf8]
UTF-8 now accepts non-character unicode points; these are not replaced
by the replacement character anymore
[ChangeLog][QtCore][QUrl]
QUrl now fully accepts non-character unicode points; they are encoded as
percent characters; they can also be pretty decoded
[ChangeLog][QtCore][QJson]
The Writer and the Parser now fully accept non-character unicode points.
Change-Id: I77cf4f0e6210741eac8082912a0b6118eced4f77
Task-number: QTBUG-33229
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's a nice feature to have.
MSVC also complains about using doubles to create enum values, so
the ugly workaround is:
enumValue = MyEnum(qRound(json["myEnumValue"].toDouble()));
[ChangeLog][QtCore][QJsonValue]Added QJsonValue::toInt().
Change-Id: I1a200b912abf66b2e96390b1980caff26cfa2685
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Need to store 17 decimal digits for binary64, IEEE 754 double formats.
Autotest is included. Test cases from TC39 test suite for ECMAScript.
Task-number: QTBUG-31926
Change-Id: I546398f21ea7ff5e40e89fc9de8703f628f55df9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Latin1 strings are usually stored as 8 bit data in the json binary
format. But that data structure has a size limitation of 16bit, so
we need to fall back to storing the string as 16 bit data if it is
too long.
Task-number: QTBUG-30946
Change-Id: I0069b1367030b0b2f819fd1f04e34c9e2534a2a3
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
In JSON, any number is stored in double. We need to make sure we
keep the maximum possible number precision for integer number. In
IEEE 754 double format, the significand precision is 53 bits(52
explicityly stored).
Autotest is included. qint64 and double work fine.
Task-number: QTBUG-28467
Change-Id: I7f857671c50e4334e9329c778f9b4f090f490540
Reviewed-by: Sune Vuorela <sune@vuorela.dk>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Previously only 32bit signed integers were ensured to be supported by
JsonValue type via API but it is expected that a larger integer range
should be supported by a JSON implementation.
This commit brings the Qt implementation into parity with NodeJS
JSON.stringify() in respect of the JavaScript Number type.
Change-Id: If91153cb3b13ecc14c50da97055b35ce42f341e7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Previously Qt JSON writer would only emit 6 digits of precision as this
is the default with the formatter.
However with testing against NodeJS JSON.stringify() this behavior is
inconsistent with the defacto standard JSON implementation and conveys
a loss of precision.
Change-Id: Ie1845a6e0ee0b4c05f63ec0062f372e891855f0b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
My interpretation of RFC4627, Section 2.4 "Numbers" of:
Numeric values that cannot be represented as sequences of digits
(such as Infinity and NaN) are not permitted.
I have also verified this matter with NodeJS JSON.stringify() that
emitting a null is consistent behavior with a JSON implementation
written in JavaScript.
Previously Qt would emit:
{
plusInfinity: inf,
minusInfinity: -inf,
notANumber: nan
}
Which maybe turned into a string values of "inf", "-inf", "nan" by
the receiving parser. Now it returns the JSON null value just like
NodeJS JSON.stringify().
Change-Id: I9f9c17f12b2606280806c47a9d90465c4ba5f786
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The writer delegate used by QJsonDocument to produce a Json QByteArray
supports generating a human readable Json (with spaces and carriage
returns that reflect the Json structure) and a less human readable (no
spaces nor carriage returns) but more compact Json.
The method toJson() was extended with a format argument to support
the compact Json generation.
Task-number: QTBUG-28815
Change-Id: I8d13849ab9ab6ed7c645011260251dc14a8629d2
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Debao Zhang <hello@debao.me>
We also need to detach() the taken value in case the compaction triggers and
modifies the underlaying data.
Change-Id: Idcdeba4236b8e208d107d41be2decbdfc5721300
Reviewed-by: Bjørn Erik Nilsen <post@bjoernen.com>
Reviewed-by: Denis Dzyubenko <denis@ddenis.info>
This allows us to follow test naming convention which should start
with "tst_"
Before:
TestQtJson::initTestCase()
After:
tst_QtJson::initTestCase()
Change-Id: Id83ccc324776399184c3665565eb8d045bfee2e2
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
