the most-common case is: queue is empty or filled with tasks of
the same priority; so the runnable would be put at the end of queue.
both checks are cheap for us.
also avoid detach()'ing by using const iterators
Change-Id: Iab2255f852211f9accc8d717f778671661210ef3
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
results are now equals to results of ICU's u_isprint() for the entire set
of the Unicode code points
Change-Id: I763f4b37cccd285eb01543d486f25bd7ea011241
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Provide support for platforms with older implementations of
realpath() (eg. iOS).
Change-Id: Iec7f73c8014d238ae6a2cb2fa836b36b89ce4ef6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@nokia.com>
This is needed to use the classes with standard algorithms
and is the Right Thing anyway.
Change-Id: I13d1e0bfabbd216319cc138f11a9b3240f093052
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
There's no need to change behaviour now. The current marker (@Invalid())
returns an empty string list, as opposed to a list with one item.
Changing it would break compatibility unpredictably with Qt 4.
So I choose not to change QSettings. Let it be "Done".
Task-number: QTBUG-25110
Change-Id: Id1f353dfed800005d927183da237f3f8357c496d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Jason McDonald <jason.mcdonald@nokia.com>
Growth computations are deferred to QArrayData::allocate, except in the
case of realloc as that functionality is currently lacking in
QArrayData. Since that sits in library code, anyway, it can be changed
later to use a future QArrayData::reallocate.
As it is, reallocData is becoming a model for QArrayData::reallocate
and what it can offer to containers of POD/movable types.
Change-Id: I045483f729114be43e4818149d1be1b333bcbe13
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In this branch, !IS_RAW_DATA has already established that offset is
sizeof(QByteArrayData) and realloc maintains the assumption.
Change-Id: Ic160e36d7781d4c4f64a3b2ebec98c9cb605b3eb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@nokia.com>
For the time being QByteArrayData keeps its independent existence, for
the sake of other modules. Once they have been ported to use the new
initializer macros it can be changed to:
struct QByteArrayData { QArrayData array; };
Extra braces can then be added to the macros.
With respect to source compatibility, the only concern is with other
modules, as QByteArrayData has already changed in incompatible ways with
Qt 4.x
Done-with: João Abecasis
Change-Id: I044e2a680317431777a098feec8839a90a3d3da3
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This eases porting to QArrayData and retains semantics. In append() and
prepend() a conditional was generalized so that no work is done if there
is nothing to add.
Done-with: Jędrzej Nowacki
Change-Id: Ib9e7bb572801b2434fa040cde2bf66dacf595f22
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@nokia.com>
In conceptual terms, this change increments the Data::alloc member by
one for all strings allocated and maintained by these classes. Instances
initialized with fromRawData retain 0 as the member value, so they are
treated as immutable.
This brings QByteArray and QString closer to QVector, making it possible
for them to reference and share the same data in memory, in the future.
It also brings them closer to QArrayData.
In practical terms all comparisons to the alloc member were changed to
take into account that it also tracks the terminating null character.
Aside from the increment in the alloc member, there should be no user
visible changes.
Change-Id: I618f49022a9b1845754500c8f8706c72a68b9c7d
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
http://unicode.org/versions/corrigendum6.html:
> in Unicode 5.0, the list of characters with the Bidi_Mirrored property
> was made consistent for brackets and quotation marks, in preparation for
> new constraints on bidi mirroring. However, after publication of
> Unicode 5.0.0 it was discovered that this change adversely affected
> several quotation mark characters in deployed data.
Task-number: QTBUG-25169
Change-Id: Id49caf401af2d5a1e6dbcc32b2f350aa20b7f901
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Fixed a bug in qdoc that caused too many end elements to be generated.
Also fixed some doc errors that caused invalid DITA to be generated.
Task nr: QTBUG-25302
Change-Id: Ifbbf457d28c51c2691a252888447739da7713bc9
Reviewed-by: Martin Smith <martin.smith@nokia.com>
Reviewed-by: Casper van Donderen <casper.vandonderen@nokia.com>
QHash employs an optimization for int/uints, squashing the hash
value and the key value inside an union. This obviously works
iff qHash(int k) = k. If the hash value gets salted, the hash
table is corrupted.
This patch removes that optimization by means of a #if 0,
so if further research finds out that we want those 4 bytes back
it's pretty simple to revert.
Change-Id: If273f0bf2ff007f4f2f7c46d2aab364a3b455cf1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The version without argument was kept for binary compatibility when
the configurable ReadElementTextBehaviour was introduced. It is now
dropped in favour of using a default argument value.
Change-Id: Ic08c41d5a5aad9f22df7fc37a2d53ffbc6df1fe9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Unfortunately, qdoc is too simple to understand any pointer to member
function syntax.
(the ::* token is not even tokenized. And even if it was, it would be a
difficult way to hack that into the parser. (there is already an ugly
workaround for non-member pointer to function hat works by having '(*'
as a token,but the same hack is not possible for pointer to member function))
So I just put verbatim 'PointerToMemberFunction'
Also remove the obsolete mention that Qt::UniqueConnection is not supported
in that overload. It is now. (And it even contradicts the previous
paragraph)
Change-Id: I8fc9544808c9a462b0f11ccea406e2e33dee15b1
Reviewed-by: Geir Vattekar <geir.vattekar@nokia.com>
Reviewed-by: Casper van Donderen <casper.vandonderen@nokia.com>
I forgot to re-add those when I re-added the non-encoded (QString)
forms.
Change-Id: I9d635d40106273177df2c332f09d66415efc15a3
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
The new QUrl is able to distinguish a URL component that is empty from
one that is absent. The previous one already had that capability for
the port, fragment and query, and the new one extends that to the username,
password and path. The path did not need this handling because its
delimiter from the authority it part of the path.
For example, a URL with no username is one where it's set to QString()
(null). A URL like "http://:kde@kde.org" is understood as an
empty-but-present username, for which toString(RemovePassword) will
return "http://@kde.org", keeping the empty-but-present username.
Change-Id: I2d97a7656f3f1099e3cf400b199e68e4c480d924
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
Based on consumer preview, the internal version is 6.2
Change-Id: I9d6ff6c7614f46a20d489e8a8f4aefeb60c547f6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
PCRE doesn't like illegal Unicode sequences (it's explicitely
documented in pcreunicode(3) that they trigger undefined behaviour,
and the program may crash). Therefore, we always let PCRE check
the validity of both the pattern and the subject string.
However, when performing global matching, the subject string
can be checked only once: subsequent matches can safely skip the check
and avoid a huge performance hit of scanning the whole subject
string for each match (!).
This patch implements that behaviour internally -- it's still
not possible for the user to skip the sanity check. On large
subject strings, this gives a terrific performance benefit.
Change-Id: Ia44cf18782e07966c9cd6ec4ccfef081ed131763
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Using g++ 4.6.1, we get warnings like below:
qprocess_unix.cpp:1376:69: warning: ignoring return value of
‘int chdir(const char*)’, declared with attribute warn_unused_result [-Wunused-result]
g++ is pretty adamant and prints the warning even if you explicitly
ignore using (void). So, just check for error and print a warning.
Change-Id: Ifd6f3b6bb9e17d44aa235815b06a762131ca8751
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
By having the default value equal to zero, we follow the principle of
least surprise. For example, if we had
url.path()
and we refactored to
url.path(QUrl::DecodeSpaces)
Then instead of ensuring spaces are decoded, we make spaces the only
thing encoded (unicode, delimiters and reserved characters are
encoded).
Besides, modifying the default can only be used to encode something
that wasn't encoded previously, so having the enums as Encode makes
more sense.
As a side-effect, toEncoded() does not support any extra encoding
options.
Change-Id: I2624ec446e65c2d979e9ca2f81bd3db22b00bb13
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
This allows things like http://example.com/{1234-5678}?id={abcd-ef01}.
But do not allow it in other parts of the URL. I could allow it in the
fragment, but in the username and password it would be too ugly.
In order to do that, make DecodeReserved use two bits and have
PrettyDecoded set only one of them. That way, toString(PrettyDecoded)
can be distinguished from toString(PrettyDecoded | DecodeReserved),
just as path(PrettyDecoded) can be distinguished from
path(PrettyDecoded & ~DecodeDelimiters).
Also, take the opportunity to avoid decoding the reserved characters
in the query. Keep them encoded as they should be.
Change-Id: I1604a0c8015c6b03dc2fbf49ea9d1dbed96fc186
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
DecodeReserved applies to all characters between 0x21 and 0x7E that
aren't unreserved, a delimiter, or the percent sign itself.
Change-Id: Ie64bddb6b814dfa3bb8380e3aa24de1bb3645a65
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
There's little value in having the DecodeUnambiguousDelimiters option
since neither QUrl nor QUrlQuery can return values that are ambiguous
in that particular context, ever.
This option could be used to encode a character if, when placed
in a URL, it would need to be encoded. Such cases are hash (#) or
question marks (?) in the path component, or slashes (/) and at signs
(@) in the userinfo.
However, we don't need two enums for that, since there are no
other characters that can appear in either form. Still, leave two bits
for this enum. In the future, if we want to split the gen-delims from
the sub-delims, we are able to.
Change-Id: If5416b524680eb67dd4abbe7d072ca0ef7218506
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
This is the same fix as the previous commit did for the other
components of the URL. But we're also changing how we handle the "[]"
characters in a query: previously the handling was like for other
sub-delims; now, they're always decoded, assuming that the RFC had a
mistake and they were meant to be decoded.
Change-Id: If4b1c3df8f341cb114f2cc4860de22f8bf0be743
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
Refactor the way that QUrl stores and returns the components of the
URL so that ambiguous delimiters (gen-delims that could change the
meaning of the parsing) are interpreted correctly. Previously, QUrl
called "unambiguous" the form found in a full URL, even though each
item in isolation could have more characters decoded.
Now, instead, store only the fully decoded form. To recreate the
compound forms (the full URL, as well as the user info and the
authority), we need to do more processing.
This commit applies to the user name, password, path and fragment
only. The scheme, host and port do not need this work because they are
special; the query is handled separately.
Change-Id: I5907ba9b8fe048fff23c128be95668c22820663a
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
0xfdef-0xfdd0 is definitely 31 and not 15 :)
also fix all copy-pastes of this code (greping for '0xfdd0' helps ;)
Change-Id: I8f3bd4fd9d85f9de066f0f5df378b9188c12bd48
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Denis Dzyubenko <denis.dzyubenko@nokia.com>
by reordering and regrouping conditions so that they lead to result earlier
in most-common usecases (l.letters, spaces and puncts, u.letters, other);
there are no title cased letters in range [0..127] -> use this in isTitleCase();
test for 0xa0 (nbsp) early in isSpace() as it is quite common in HTML, etc.;
add early test to isNumber().
Change-Id: Ib415f34cb1212d9ccf8753de2d1beaece1aa2243
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Removed some MacOS source code files from iOS build. Use unix standard
paths for now (iOS-specific implementation will come later).
Change-Id: I8b2731b431b3a379a1ec4ec07d227e886209e3e9
Reviewed-by: Morten Johan Sørvig <morten.sorvig@nokia.com>
Just like qMalloc/qRealloc/qFree, there is absolutely no reason to wrap these
functions just to avoid an include, except to pay for it with worse runtime
performance.
On OS X, on byte sizes from 50 up to 1000, calling memset directly is 28-15%
faster(!) than adding an additional call to qMemSet. The advantage on sizes
above that is unmeasurable.
For qMemCopy, the benefits are a little more modest: 16-7%.
Change-Id: I98aa92bb765aea0448e3f20af42a039b369af0b3
Reviewed-by: Giuseppe D'Angelo <dangelog@gmail.com>
Reviewed-by: John Brooks <john.brooks@dereferenced.net>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Konstantin Ritt
Lars Knoll
Sergio Ahumada
Qt4iOS
hjk
Thiago Macieira
João Abecasis
Jędrzej Nowacki
Stephen Kelly
Martin Smith
Giuseppe D'Angelo
Giuseppe D'Angelo
Thorbjørn Lindeijer
Olivier Goffart
Shane Kearns
Girish Ramakrishnan
Robin Burchell