Since qt-internal-configure-tests.bat is located in the same folder as
qt-cmake.bat the relative_path_from_libexec_dir_to_bin_dir is empty.
Passing doubled backslash in the windows path causes an issue for the
cmd.exe batch interpreter. Extra backslashes are treated by %~dp0 as a
start of the relative path. The following error appears:
Could not find toolchain file:
...\install\bin\..\/../lib/cmake/Qt6/qt.toolchain.cmake
This appends an extra backslash to relative_bin_dir only if
relative_path_from_libexec_dir_to_bin_dir is not empty.
Change-Id: Id2fd6c5fa9d73060350f298262c6e93a4887eeb3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This should reduce the amount of fall-out from DST complications.
Also document the assumptions of QDateTimeParser's two fromString()
methods (and fix the punctuation on the QDateTime parameter).
Adjusted some tests to match.
Since only QDateTime-returning methods will show the difference, and
it's at least somewhat odd to be using those on QDateEdit or
QTimeEdit, this should have little impact on API users.
[ChangeLog][QtCore][Behavior Change] QDateEdit and QTimeEdit now
operate in UTC, to avoid spurious complications arising from time-zone
transitions (e.g. DST) causing the implicit other half to combine with
the part being edited to make an invalid result. Returns from their
dateTime() and other methods returning QDateTime (max/min) shall thus
be in UTC where previously they were in local time. QDateTimeEdit
continues using local time. The default can be over-ridden by
setTimeSpec(), as ever.
Change-Id: I44fece004c12342fe536bbe3048217d236fd97b2
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Thanks to Giuseppe for pointing it out in API change review.
Task-number: QTBUG-94407
Pick-to: 6.2
Change-Id: I3b8fb653b5efa7ded51f81aadb35d361e7dbf19c
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
QDTP's absoluteMax(), setDigit() and getDigit() simply treated
day-of-week as synonym for day-of-month.
Consequently, QDTE::stepBy() did the same.
This meant that wrapping happened at the month boundary, so would jump
within the week if it wrapped around, otherwise the up/down arrow
would "jam" at a particular day of the week when further steps would
leave the month. Instead, when wrapping, wrap round the week while
still moving the day-of-month to match, jumping back or forward a week
to stay within the month on hitting a month boundary; otherwise, stop
backwards stepping on hitting the locale-specific day of the week, or
forward stepping when the step would be to or past this first day.
Fixed various bugs found in the course of testing this.
[ChangeLog][QtWidgets][QDateTimeEdit] Corrected handling of weekdays.
Previously, changes to the week-day were simply changes to the day of
the month. Weekday fields are now handled as such: changes to them do
change the day of the month, but a change that would step past the end
(or start) of the month is adjusted to the relevant day of the nearest
week within the month. When wrapping is disabled, the locale-specific
first and last days of the week are the bounds. Formats which specify
day of week but not day of month will now preserve day of week when
changing month or year, selecting the nearest day of month that
matches.
Change-Id: I7868b000fea7a4bc17a1b5687c44bcd56d42ae90
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
If QMAKE_APPLE_DEVICE_ARCHS is not set, we pick up the available archs
based on what Qt was built with (QT_ARCS), but only build the active
arch.
Pick-to: 6.2
Change-Id: I83273f878022af34a3a0d0eeae8b11d781f78c49
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In the case of a plugin, the plugin might be unloaded, and destroy its
QGuiApplication. We don't want the screen notification handlers to outlive
the application, as that results in crashes.
Fixes: QTBUG-91919
Pick-to: 6.2 6.1 5.15
Done-with: Yang Yang
Change-Id: I3a4c0fcf97b785357516d1dac34489511400f154
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Also remove handling of older versions, because we only support
Visual Studio 2019 currently
Pick-to: 6.2
Change-Id: If66a46d970047fe25582e323df74e0a904ee92da
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
In general, QEventLoop::exec() _can_ be used as-is on
WebAssembly, provided that the event dispatcher supports
the use case.
Use cases that can work include calling exec() on a
secondary thread, or calling exec() on the main thread
if asyncify is used.
Some use cases will still require special casing for
Wasm, such as the non-asyncified QApplication::exec(),
but that can be handles closer to where the workarounds
needed, for example in QApplication.
This removes the partial support for nested event loops
on the main thread, which did not really work. Also,
we no longer call emscripten_force_exit() on QEvetLoop::exit(),
which makes it possible to exit a top-level event loop
without exiting the process.
Task-number: QTBUG-70185
Change-Id: I3a28f41b8547ed3ba1bdf6a835e6662483e34449
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
This is the wrong event: exiting the app here it is not
compatible with the back/forward cache for instance. See the
the MDN docs for the “Window: unload” event.
Instead, make the Qt default be that we assume the
app process will live “forever” until the browser
terminates it, much like modern process handling on
e.g. iOS.
We may want to come back to app lifecycle handling
at a later point. This might require changes to application
code: implementing main() in such that it supports
clean shutdowns and auditing showdown code to make
sure it is web-compatible.
Change-Id: I0f32026a3af76c9cc79e3aab31e8aaed7b8f8023
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Go with Emscripten’s default of not shutting down on
main() exit; this allows for writing main() in such
a way that avoids the exec() workaround.
Existing main() implementations (which do use the exec()
workaround) do not shut down Qt cleanly anyway, so we
gain little by shutting down the Emscripten runtime.
Applications can set this flag if they do want to shut
down on main() exit:
LFAGS += -s EXIT_RUNTIME=1
Change-Id: I52e1cc2bc907d1d2146822713e39b7610db3f95b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
This commit adds an opt-in mechanism to kill type-unsafe functions
and implicit conversions of QFlags, therefore removing an entire
category of bugs that QFlags itself is supposed to protect against:
QFlags<E> f;
f == 3.14; // OK; f->int, int->double, then operator==(double,double)
f & UnrelatedEnum; // OK if of unscoped enum, calls operator&(int)
f &= 123; // calls QFlags::operator&=(int)
int i = f * 42; // f->int, then operator*(int, int)
Thankfully, operator+ and operator- had already been deleted.
By defining QT_TYPESAFE_FLAGS one:
* disables operators taking (u)int, forcing the usage of an enumeration
or another QFlags object;
* turns the implicit conversions towards integers/bool in explicit
(one can always use fromInt/toInt instead);
* adds a convenience set of (in)equality operators against literal 0,
in order to keep code like `(flag & bit) == 0` compile. This set can't
be added normally otherwise it would add ambiguity;
* adds the unary operator~(Enum), turning it into a flag. This is
a source incompatible change, in general, so it's opt-in.
This is a Qt-internal macro at this point. It can't be offered to users
yet because we need to fix some public API flaws first: in some places
(e.g. QPainter::drawText) we ask users to do type-unsafe manipulation
of flags. A user enabling the macro wouldn't be able to properly use the
functions in question.
This macro will be enabled in a follow-up commit.
Change-Id: I796f2256b446bafc12cdcbaf7de417d12bd3619e
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Which is not a trivial class.
qstringbuilder.h: In instantiation of 'static void QConcatenable<const char16_t [N]>::appendTo(const char16_t*, QChar*&) [with long long int N = 6]':
qstringbuilder.h:402:35: required from 'static void QConcatenable<QStringBuilder< <template-parameter-1-1>, <template-parameter-1-2> > >::appendTo(const type&, T*&) [with T = QChar; A = char16_t [6]; B = QString; QConcatenable<QStringBuilder< <template-parameter-1-1>, <template-parameter-1-2> > >::type = QStringBuilder<char16_t [6], QString>]'
qstringbuilder.h:460:52: required from 'QString& operator+=(QString&, const QStringBuilder<A, B>&) [with A = char16_t [6]; B = QString]'
/home/tjmaciei/src/qt/qt6-release/qtdeclarative/src/qml/jsruntime/qv4qobjectwrapper.cpp:1762:75: required from here
qstringbuilder.h:338:15: error: 'void* memcpy(void*, const void*, size_t)' copying an object of non-trivial type 'class QChar' from an array of 'const char16_t' [-Werror=class-memaccess]
Change-Id: Iddb933f281024939b6acfffd1689cf320c84873c
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
The spurious warning is not emitted any more by GCC 10 / 11.
Even if it's still emitted by earlier GCC versions, now it's no longer
an error.
Change-Id: Ia8bf3e10905909c097ecc025bf89f818410a8dae
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There's a number of upstream bugs that cause false positives;
do not make them errors.
Change-Id: I4151794d8d37177a47a34aef8d83accf4377d44a
Pick-to: 6.1 6.2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
If we disregard the precision we may read a very large string that we
subsequently discard. Furthermore, people use this to read
non-null-terminated strings, which randomly crashes.
Pick-to: 5.15 6.1 6.2
Change-Id: Ifa255dbe71c82d3d4fb46adfef7a9dc74bd40cee
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Like AESNI, RDRAND is an optional extra feature that is not always
enabled in all parts. Probably something to do with export restrictions,
but I've only seen that in low-end parts.
Drive-by removal of "AES" where it was no longer relevant.
Pick-to: 6.2
Change-Id: I7246c3e7bb894e0d9521fffd168af3fc0fb638a1
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Use nullptr instead of 0 for null pointers.
Compare OCIHandleAlloc() return values to OCI_SUCCESS rather than 0.
Initialize instance variables in the class where possible, rather than
in the constructor. Conform to coding style o long lines and braces.
Assert pointers are null before allocating and overwriting them, so we
might have a chance of catching leaks.
Change-Id: Ia885ec18f46de5219a51fb6f9f23f474b3046585
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
QOCIResult::~QOCIResult() was doing part of the tidy-up for
QOCIResultPrivate, whose own destructor took care of the rest.
So move that part to the private, where it makes more sense.
Also correct an error message in part of the private's existing
tidy-up and eliminate a needless local variable.
Change-Id: I09a51c72afd7a30bcee7f6127c59d703650f1c41
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
If d->sql is non-null, it gets freed; later in the same function, it
gets reallocated, unless the query is empty, in which case the
now-freed value was still recorded, so that later clean-up might find
it and mistakenly think it needs to be freed again. Clear when freeing.
Pick-to: 6.2 6.1
Change-Id: I8d37d2ba1fcaa320916eaf30dceaa720bbf62f38
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Transaction handles were allocated but nowhere freed. Thanks to Stefan
Latsch for pointing this out and suggesting the fix. Make the handle
yet another member of QOCIDriverPrivate so that close() can free
it. At the same time, also free the service context handle d->svc when
failing do open(); and shuffle the order of frees to be the reverse of
the order of allocations.
Fixes: QTBUG-94246
Pick-to: 6.2 6.1 5.15
Change-Id: I45818ada6d884b06028056d28635390a300e2def
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
MetaMethods is a std::vector, so we should avoid copying it. Add
strategic std::move()s and pass to the TestFunctions ctor by value,
not cref.
Change-Id: Iaa2879ae427b9603a7abaab0e3015556d9c247fc
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Make Emscripten generate a global constructor function
("createQtAppInstance()") instead of a global javascript
module object.
This enables more fine-grained control over module
instantiation; previously the module object would be
created when the runtime javascript was evaluated, and
the number of emscripten module/instances was limited
to one per page.
Set EXPORT_NAME to “createQtAppInstance” which avoids
collisions with other non-Qt Emscripten modules on
the same page. A further improvement would be to include
the app name in EXPORT_NAME, but this is not done at
this time.
Update the code in qtloader.js to call the constructor
function instead of working on a global module object.
The qtloader.js API is functional before the wasm and
Emscripten modules have been instantiated; store properties
and forward to the Emscripten module when it's created.
Change-Id: I12c49a5b9a4a932bbc46fcc5e5ecc453fd0fe7f0
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Depending on build options, the module can have a different
name, or be a non-global object. We were already using
module_property in many places, but some were missing.
In the case of the clipboard code, there is actually
no need to export all of the C++ functions to JavaScript
and then resolve them from the module; instead call them
directly.
Change-Id: I83aa3ad01ad961d48e21f0994e0c205d833cbe8a
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Remove event listeners on shutdown. For emscripten
event callbacks this can be done by passing nullptr
as the callback, for DOM event listeners use the
“removeEventListener” API.
Change-Id: I5a32a6a8feb906082db5ef3d0a0cd7ecb3b54292
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
m_compositor and m_eventTranslator are owned by the
screen object and can be held in a unique_ptr.
Pick-to: 6.2
Change-Id: I7d5e19e7ac6f762f360d6af0fc9500e6964f737e
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
... even though the documentation states that the action takes
ownership of the widget.
Change-Id: Ie5520fbda295a5a2774ff8b82165070e9d49e310
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
We can get better performance if we omit unlocking the mutex before
relocking it in startAsyncRead().
Change-Id: Ia012a71b95876d4f90c1dc4b7db5d7b267fca7a6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
new syntax rules for EXTRA_EXPORTED_RUNTIME_METHODS valid after 2.0.16
Pick-to: 6.2
Change-Id: Iff33e4c6f3176619fb35ec0994a7cc87b5d937c7
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
An initial EOF check is not required here because the code below
correctly handles this case. Also, the condition '!pipeBroken' means
that the pipe reader is in the 'Running' state.
Change-Id: I608d932c4e38f8224d9e655272e61295e55414e0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Remove the temprotary 'Private' targets of the iternal modules.
Pick-to: 6.2
Task-number: QTBUG-87775
Change-Id: I9a2c7c8c2f63602476fd935b11dab7a835864537
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The setlocale call will only give useful results if the program
had previously set the current locale using setlocale...
See also "Compose Locale" section in xkbcommon doc:
https://xkbcommon.org/doc/current/group__compose.html#compose-locale
Fixes: QTBUG-85529
Pick-to: 6.2 6.1 6.0 5.15
Change-Id: I65b1ac86ea54445bc3a2e1707df79bd9f732ab46
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
If __qt_internal_propagate_object_library is used to propagate an
imported object library we assume that the library is already compiled
and no need to apply properties that may affect compiling and further
linking of the target.
Amends 3329212815
Pick-to: 6.2
Change-Id: I2bd03264e286439fbed9067fa2c0a5c4a0097856
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The qt-conan-common package contains shared functionality
for recipes that should be used:
- environment wrap during the build()
- package_info() is generic for all recipes
Move the _build() out from the class so that it is usable for
the callback from qt-conan-common package.
Simplify how the Qt module version and prerelease tag is
read from .cmake.conf and how the file is being referenced.
As the .cmake.conf is included in the "exports" it will
be always present next to the recipe:
- in .git source tree
- in Conan cache
Pick-to: 6.2
Change-Id: I4bbd683f7b49151620397e0b7f4272929a93c060
Reviewed-by: Toni Saario <toni.saario@qt.io>
The status information (alpha1, beta2, rc3, ...) needs to be part of
the Conan package reference.
As Conan supports semantic versioning the best place to put the status
is to append it to the version string:
qtbase/6.2.0-alpha1@qt/everywhere
qtbase/6.2.0-beta2@qt/everywhere
qtbase/6.2.0-rc3@qt/everywhere
qtbase/6.2.0@qt/everywhere
Other Conan packages declaring a dependency can use e.g. syntax:
# notice the asterix character after version
self.requires(f"qtbase/[<=<version>, include_prerelease=True}]@..)
This way the status information is not in the Conan channel part and
downstream consumers of the Conan package does not need to update
the dependency (Conan reference string) every time the version changes.
Put the status information next to Qt version string in .cmake.cache.
Task-number: QTBUG-94385
Pick-to: 6.2
Change-Id: Ib277f99ea1e87253b93f59e463bd6c7dd8b3203e
Reviewed-by: Toni Saario <toni.saario@qt.io>
The code uses std::numeric_limits but is lacking the appropriate include
Pick-to: 5.15 6.1 6.2
Change-Id: I41fa5ac4d8c4e06f35b5b1551ef2ad8417df80bd
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
The compiler generated ones are broken. The RO5 exists for a reason...
Change-Id: Ibaa5322a7a1ad4ad06bd00e9d1c21bbbea6eb08c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Both the call to setProcessState(QProcess::NotRunning) and deleting
the PROCESS_INFORMATION structure are redundant here. All this work
was done by the previously executed cleanup() call.
Change-Id: Iaf89f5edd2b661008a479d154e68974621b1b1eb
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Dependency lookup mechanism is the same for modules and plugins. It
makes sense to wrap it using macro.
Pick-to: 6.2
Change-Id: I73727743b0f5f40b2d94624f65ebfcf85e8dcc59
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
