This is the correct mapping, and as a bonus the Chrome browser provides
a stack trace on all output from console.warn().
Change-Id: I4a1b95475679d6b54a0690f51c23683514fe7985
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: David Skoland <david.skoland@qt.io>
The fsevents implementation of QFileSystemWatcher on Mac OS X tries to
remove trailing slashes from the paths when calling addPaths(). If the
user tries to watch "/", the path is changed to "".
The fix checks whether the path is longer than 1 before removing
trailing slashes.
Change-Id: Iafb10e449c4f3bd600b02edbe7c549911db05048
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This avoids repeated re-instantiations of unique_ptr with local
deleters, removing that instantiation from the top of the list in
Clang -ftime-trace QtWidgets builds:
**** Templates that took longest to instantiate:
2627 ms: std::__1::unique_ptr<void, free_deleter> (835 times, avg 3 ms)
Amends e297e80fd0.
Pick-to: 6.3
Task-number: QTBUG-97601
Task-number: QTBUG-99039
Change-Id: I1281f6cf9248a3796d9dfdc653f19f5a67dc3bda
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Remove .as_handle() call, which was left over from the previous
EM_ASM-based code; see 0ec75f4b9.
Change-Id: I220304074f4d17e706726dab086c0330edc9ef25
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
qmake adds QMAKE_PRL_LIBS values on the link line after the currently
processed library. Because CMake adds resource object files into
QMAKE_PRL_LIBS, they end up on the link line after the library.
This causes issues on Linux with GNU ld and ld.gold, because the
linker discards symbols from the library which are then later referenced
by the object files.
Work around that by placing the path to the library directly into
QMAKE_PRL_LIBS after the resource object files.
This ensures the linker doesn't discard the symbols required by the
resource object files.
This means that each library encountered in qmake's LIBS variable will
be temporarily referenced twice in qmake's project state: once from
LIBS / QMAKE_PRL_TARGET, and once when the QMAKE_PRL_LIBS values are
added. On the link line it will appear only once though, because qmake
does library deduplication during prl file processing, which only keeps
the last occurrence.
Amends 4ab5432081
Pick-to: 6.2 6.3
Fixes: QTBUG-103002
Change-Id: I97647b64de22b158424850915fee62b5fea5f995
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This reverts commit 6feb289189. It causes
a crash when field.myField is null.
Fixes: QTBUG-102489
Pick-to: 6.3
Change-Id: I7e305799c8594ebab255fffd16ee1a41cac8d387
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Since we still don't support dynamic linking in wasm, we can't
use it for tests, which forces us to use static linking, which is
very slow (up to 30 seconds in some cases). The idea is to at least
have one test run for wasm before expanding it later.
Note that even with this change,
QT_BUILD_MINIMAL_STATIC_TESTS=ON needs to be defined to skip
the baseline test directory.
Change-Id: I39aea22087211fb39f03dfb0b39c55f63a26d2a7
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
All module header files should be listed in the corresponding sections
of modules SOURCEs to be accessible in CMake routines.
Task-number: QTBUG-103196
Change-Id: Ieb77ae70557e35e546a5b00387e1e0aa40338239
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Don't deliver update requests to windows which have been deleted
or are not on screen.
Change-Id: Ia2972e8dbef46eaf91a45a84962353917d436da6
Reviewed-by: Aleksandr Reviakin <aleksandr.reviakin@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: David Skoland <david.skoland@qt.io>
QWasmCompositor currently has the requirement that destroying it
requires freeing a GL texture, which requires a valid GL context,
which requires a valid screen, in order to get to the native context
on the canvas.
For this reason QWasmScreen has a destroy() function which is called
before deleting the QScreen and QPlatformScreen.
Make sure we call destroy() also when deleting all screens in the
QWasmIntegration destructor. Move the common logic into a new
deleteScreen() function which replaces destroy().
Change-Id: I628f13c868808db539effff9b29ecbefac23abc9
Reviewed-by: Aleksandr Reviakin <aleksandr.reviakin@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: David Skoland <david.skoland@qt.io>
JavaScripts's BigInt feature provides support for arbitrary-precision
integers. This makes it possible to represent 64-bit integers; the
standard JS Number type supports 32-bit integers only (or more
accurately 53-bit integers - see Number.MAX_SAFE_INTEGER).
Enable WASM_BIGINT which makes Emscripten map int64_t and uint64_t
to BigInt when interfacing with JavaScript code.
This removes one of the conditions which enables
wasm-emscripten-finalize.
Task-number: QTBUG-103352
Change-Id: Ia70d599daaf34c92695f5a2b61665e0c237e6b95
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: David Skoland <david.skoland@qt.io>
This removes one of the conditions which enables
wasm-emscripten-finalize.
Task-number: QTBUG-103352
Change-Id: Id05db4b081dec360cdad2e611622e5baf09aeb23
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: David Skoland <david.skoland@qt.io>
find_library does not always work because libatomic.so may be in a path
like /usr/lib/gcc/x86_64-linux-gnu/11/libatomic.so, which CMake does not
consider by default.
Pick-to: 6.3
Change-Id: I73a657c470efa4f84f8629bd531edfcac3b3a352
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
During type normalization, we remove the struct, class and enum
keywords (see the skipStructClassOrEnum function). However, we only want
to do that for actual keywords, not for a name that happens to start
with e.g. "enum", as in "enumerationNameSpacce".
Adjust the MSVC check to still require no identifier character after the
keyword, while still allowing for some remaining characters.
Fixes: QTBUG-97813
Pick-to: 6.3 6.2
Change-Id: I82b873d02ff454cce4b75f2814a52a66f2268208
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QDBusConnection::closeConnection does not use deref() on pendingCall
list so if there is an QDBusPendingCallWatcher watching the
pending call the QDbusPendingCallPrivate destructor will
run twice causing a crash.
Pick-to: 5.15 6.2 6.3
Change-Id: Ib811da36d3510f4292aa310c52c0617b885947b7
Reviewed-by: Johannes Rosenqvist <xeroc81@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We don't support it any more. I don't think it has ever properly
compiled Qt 6 (and it's no longer working for me against GCC 12's
libstdc++ headers). If you report a bug against it, Intel support's
first question is if you can try instead the new Clang/LLVM-based oneAPI
C++ compiler.
So we support only that one, which identifies itself as Q_CC_CLANG.
Change-Id: I5ff8e16fcdcb4ffd9ab6fffd16eb57a092c8439e
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
I don't see a way this can be anything but a bogus warning.
In member function ‘std::__atomic_base<_IntTp>::__int_type std::__atomic_base<_IntTp>::fetch_or(__int_type, std::memory_order) [with _ITp = int]’,
inlined from ‘static T QAtomicOps<X>::fetchAndOrRelaxed(std::atomic<T>&, typename QAtomicAdditiveType<T>::AdditiveT) [with T = int; X = int]’ at qatomic_cxx11.h:449:33,
inlined from ‘T QBasicAtomicInteger<T>::fetchAndOrRelaxed(T) [with T = int]’ at qbasicatomic.h:168:36,
inlined from ‘int switch_on(QAtomicInt&, int)’ at qfutureinterface.cpp:97:31,
inlined from ‘void QFutureInterfaceBase::setThrottled(bool)’ at qfutureinterface.cpp:194:18:
atomic_base.h:648:33: warning: ‘unsigned int __atomic_or_fetch_4(volatile void*, unsigned int, int)’ writing 4 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
A few more of those appear in other modules. I'm not fixing them all,
assuming GCC will soon fix the warning.
Pick-to: 6.2 6.3
Change-Id: I7fb65b80b7844c8d8f26fffd16e93f68e278d048
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This one seems to have been forgotten the first time around.
Amends f438d29b6f.
Task-number: QTBUG-97601
Pick-to: 6.3 6.2 5.15
Change-Id: Ia9b2667dd69cc4a9778f8c9bdf905ca11b4e079e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Both tests in the conditional depend on the
qnetworkinterface feature, and will fail to build
if qt is configured without the networkinterface feature.
Additionally, a missing system header in a test was added.
Change-Id: Ife5989ee57675ebe117de2c92a4f96c7125cbab1
Pick-to: 6.3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Unsetting CMAKE_STRIP and including CMakeFindBinUtils to find it again
is not safe, because CMakeFindBinUtils has logic to search for
additional tool names depending on the currently processed language.
The currently processed language is set in _CMAKE_PROCESSING_LANGUAGE
only when CMake is doing it's language introspection via
CMakeCXXCompiler.cmake.
This resulted in the build system finding a regular host-OS strip,
rather than an android specific llvm-strip when doing an Android
build, which then silently failed to strip the Android libraries
and caused us to ship big binaries.
Improve the strip wrapper creation in a few ways:
- Save the original strip value on first configuration
- Restore it if needed, without using CMakeFindBinUtils
- Don't apply the strip wrapper creation logic to Android,
we currently don't need it there
- Add some informational messages about which CMAKE_STRIP
ends up being used even if log-level is not DEBUG
- Fix a typo
Amends 39f657032b
Pick-to: 6.2 6.3
Fixes: QTBUG-103356
Task-number: QTBUG-101653
Change-Id: I23d98180446d5bb7628e783668f46e4e546ed700
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
...when QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is ON.
When QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is ON, we want to set
QT_FORCE_BUILD_TOOLS. But this happened too late: after the
initialization of QT_BUILD_TOOLS_BY_DEFAULT. This value depends on
QT_FORCE_BUILD_TOOLS.
This amends commit acfbe3b779.
Change-Id: Ibdba54da943aea1b55618f10d2b8485f4390878a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Just a missing #ifdef.
Pick-to: 6.2 6.3
Fixes: QTBUG-103370
Change-Id: I4fc4605317d423acbf6280307362a087e427761b
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
PCRE 10.40 requires C99 now. While all GHS compiler versions we support
in Qt 6 default to C99, GHS v2016.5.4, which we use in Qt 5.15, still
defaults to C89, so set QMAKE_CFLAGS_C99 for that compiler. It doesn't
hurt in Qt 6, but enables the updated PCRE in Qt 5.15.
Pick-to: 6.3 6.2 5.15
Change-Id: I0a2d3254f80136210289a415ede7c2409b07af9b
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Kimmo Ollila <kimmo.ollila@qt.io>
This can be really helpful for deleting shortcuts that one may never
intend to use so that they do not accidentally get in the way while
interacting with the user interface.
The workaround is to try to find the QLineEdit child of the
QKeySequenceEdit widget, but it is suboptimal. Some first-class citizen
API for this would be a more stable and cleaner solution as opposed to
poking implementation details as a user of the QKeySequenceEdit API.
The clear action would be configurable and opt-in as not everyone may
potentially want this to be turned on. Or at least, not by default
anyway. Also, not to suddenly change existing QKeySequenceEdit uses with
surprising UI changes after a Qt upgrade, this needs to be opt-in.
Moreover, some customers may have already used findChild<QLineEdit *>()
to add actions to QKeySequenceEdit in this way on the client side. So,
if it was enabled by default, they would suddenly get multiple actions
potentially for the same clear action. This would be certainly
undesirable.
The new clear property is based on the corresponding QLineEdit API for
consistency.
[ChangeLog][QtWidgets][QKeySequenceEdit] Added a clear action to
QKeySequenceEdit to be able to remove existing hotkey configurations.
Change-Id: I3a90bfacd49bff10c1284abb155d7edd4f537900
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
This also includes the fix for x-objc++src mimetype.
Fixes: QTBUG-70739
Pick-to: 6.3 6.2 5.15
Change-Id: I24f70fa5cea2e5b1a7877569be98d36878fcfe72
Reviewed-by: David Faure <david.faure@kdab.com>
Apple introduced UITextInteraction in iOS 13, which
caused issues with our text handling, and resulted in
e00d888dae. This, again, seems to be the reason why
UIKit in some cases simply removes the input delegate
from our text responder. This typically happens after
a QPlatformInputContext::reset(), and then when the
next character is typed on the input panel (and hence,
leaves no informative stack trace).
The result of removing the input delegate, which is the
interface that let's Qt communicate IM changes back to
UIKit, leads Qt and the UIKit out of IM sync. E.g for a
japanese keyboard, after a QPlatformInputContext::reset(),
the Qt input field would remove the marked text, but
UIKit would still show japanese characters
based on what used to be marked text.
To work around this issue, this patch will therefore
recreate the text responder when Qt tells us to reset.
This will cause the first responder to change, which will
apparently also reset the UIKit IM state.
Fixes: QTBUG-102960
Pick-to: 6.3 6.2 5.15
Change-Id: I00901e980874fae819cc7d89a68fa34ae44808c2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We provide a bundled version.
We didn't before when the commit was initially introduced, because we
thought we'd depend on a 3rd party package manager, but we didn't
follow through on that.
Amends 5668522413
Pick-to: 6.2 6.3
Fixes: QTBUG-103245
Change-Id: Ia4cb1340bbf3f4ffb3849d658d72e7cb6c7e2fb0
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Do what all other backends do. If we did not want to reset the pipeline
tracking pointer, then more logic would be needed, in order not to end
up in trouble with clients that do:
loop:
create a pipeline // [1]
beginpass
... // use the pipeline
endpass
readback
finish
destroy the pipeline
goto loop
...because we may get the exact same pipeline pointer (with a matching
generation even since it's always 1 in this case) in the different
passes, just because malloc decided to do so in [1]. This could be
solved by checking the global resource id but won't do that now as no
other backends do it either.
This solves random broken rendering with the Qt Quick 3D lightmapper.
The above outline is exactly what the UV rasterization stage does.
Pick-to: 6.3 6.2
Change-Id: Id74a0a336634d99092181b09dd7137eaec355d48
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
This was forgotten when implementing QTBUG-73160, but suggested in
passing in QTBUG-64.
[ChangeLog][QtGui][QPolygon] Added toPolygonF().
Task-number: QTBUG-73160
Task-number: QTBUG-64
Change-Id: I9b33cf47a0d432aa842ab0f8337001c66e4ca41c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Fix bug where the device independent QWindow size was
set incorrectly, due to usage of incorrect screen and
scale factor. This could happen when a window's screen
was set to QGuiApplication::primaryScreen() as a fallback,
before QWindowsWindow::initialize() would determine the
correct screen.
By sending the screen change first we make sure that
that QWindowSystemInterface::handleGeeometryChange()
uses the correct screen for the window.
Change-Id: I5520ae67a4db60903d38db856fc314c75a3c0219
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Piotr Srebrny <piotr.srebrny@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
This speeds up creating a QGraphicsTextItem by 14% in an optimized build
Before: 0.070 msecs per iteration
After: 0.060 msecs per iteration
Those connects were showing up when profiling, because of the string
parsing that is necessary when using SIGNAL/SLOT macros.
The stacktrace was connect() => decodeMethodSignature() => argumentTypesFromString()
=> QArgumentType constructor => qMetaTypeInternal(const char*).
Pick-to: 6.3 6.2 5.15
Change-Id: I3cf5655c5450f121005140bdb587fafa083cce6a
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Use uint64_t instead of quint64 as this code is not namespaced
and to align it with the x86 code path.
Pick-to: 6.2 6.3
Change-Id: I887ef9314a80cfcc17701eac1ec9a086f3cd5bf7
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
FcFontList can return null pointer in failure cases which would lead to
null pointer dereference further down.
Pick-to: 5.15 6.2 6.3
Change-Id: I6b407cf2f27ead9eb471d3ee7a521468cebf7572
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Drag and drop into the browser will work.
Drag and drop out of the browser will not.
Fixes: QTBUG-102242
Change-Id: Id9981ab6f9514535e1409bec18068790833a67a6
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
YIELD is ARM's equivalent of x86's PAUSE, available since ARMv6k,
which should be old enough that we can use it unconditionally.
The ARM manual[1] defines the __yield() intrinsic for this, however:
- Clang has __builtin_arm_yield, the naming is compatible with what
GCC would use, so we use that if available, to avoid having to
include even more headers.
- GCC (incl. 12) doesn't have __yield() in arm_acle.h or anywhere
else, and it doesn't seem to have the builtin (yet, one can always
hope), so we use asm() there.
- Windows doesn't have an arm_acle.h header, but the docs[2] say it
should have __yield(). Unfortunately, the docs don't say where
the intrinsic is hiding, but we already include <intrin.h>, and
godbolt[3] confirms that's sufficient to use __yield(). We could use
YieldProcessor(), but we'd need to include qt_windows.h, I guess,
which I'd rather not.
- Integrity doesn't have the arm_acle.h header, we use asm(), here, too.
[1] https://developer.arm.com/documentation/dui0472/k/Compiler-specific-Features/--yield-intrinsic
[2] https://docs.microsoft.com/en-us/cpp/intrinsics/arm-intrinsics?view=msvc-140
[3] https://godbolt.org/z/Evfe79xhE
Pick-to: 6.3
Fixes: QTBUG-103011
Change-Id: Ibf496dfe9949f9a3d24c0dcf75a703c5fdbbb4b8
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
For the WM_SETTINGCHANGE message, lParam sometimes may be NULL [1]
and that will lead to crash without extra safe guard.
Amends commit qtbase/1ed449e168af133184633d174fd7339a13d1d595
[1] https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-settingchange
Change-Id: Ibd1e94b4c1d7882db0719c31a66a5fcc9299c3bd
Reviewed-by: Nodir Temirkhodjaev <nodir.temir@gmail.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* The rect passed to QToolTip::showText() is in view coordinates,
not in global coordinates.
* Determining this rect in the first place doesn't need calling view->visualRect(index)
The view already did this before calling this method, and stored it in
option.rect, so just use that.
* The widget passed to QToolTip::showText() should be the viewport,
that's what option.rect is relative to (thanks Giuseppe!).
Found these issues when implementing my own tooltip handing (for a subrect
of a delegate) by looking at this code.
Pick-to: 6.3 6.2 5.15
Change-Id: I852e5409def28da98137cd0c4c996083e5e45706
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The previously defined padding for the tab content was
overwritten to 0 by a more specific css selector. In addition,
code snippets should not have any extra padding, hence the :not(.pre)
css selector.
Pick-to: 6.3
Change-Id: I8f331924c5d01c8971660bb7a5b3aad25e3dee8a
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
Fix the documentation to show the actual header and module
Fixes: QTBUG-99335
Pick-to: 6.3 6.2
Change-Id: I333a5a95a448fdf3e08801bf794c93b87cd1f81f
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Reviewed-by: Nicholas Bennett <nicholas.bennett@qt.io>
This removes the hack that creates a copy of bootstraplib sources to
avoid rebuilding the world if a bootstraplib source file changed.
Said hack led to confusing behavior:
- when accidentally editing bootstraplib copies instead of the real
sources
- when header files were changed in a way that were incompatible to the
bootstraplib source copy
This reverts commit 80a8ead08d.
This reverts commit 743bb66744.
The official way to avoid the QTBUG-92269 problem is now to set
QT_HOST_PATH=<host-Qt-installation> and QT_FORCE_FIND_TOOLS=ON.
If you want to build the tools as well, set QT_FORCE_BUILD_TOOLS=ON.
Fixes: QTBUG-92269
Change-Id: I226bf5792f9ca8e7e207dc53e01c2903018d82d3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The install prefix was determined incorrectly for static relocatable
builds. The reason was that for those builds, QLibraryInfo::path()
returns the application directory, which is <prefix>/bin for qmake and
qtpaths.
Fix this by removing the bin directory part from the installation prefix
that QLibraryInfo returns if qmake/qtpaths are used.
Fixes: QTBUG-102877
Change-Id: I2e9ff96ded0ee2a7802b265741a3cfbe2bf0a4ba
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The current [basic.life] wording seems to cover the existing code, but
IIRC, older versions of [basic.life] were not so relaxed. In
particular, while not completely pertinent, the second placement new
is awfully similar to http://eel.is/c++draft/ptr.launder#example-1
Just make all of this SEP and use std::optional. That way, the code
gets simpler, too, plus we get rid of the last use of C++23-deprecated
std::aligned_storage.
The reset() before the 2nd emplace() isn't necessary, but, in a test,
it doesn't hurt, either, and keeps code readers from guessing whether
the first-emplaced object's dtor is actually properly run (it is).
Pick-to: 6.3 6.2
Fixes: QTBUG-99122
Change-Id: If31a46f8be3a74499f1176133029d097faf7dfe9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's deprecated in C++23. Just use an explicitly-aligned char array
directly, wrapped in a struct to avoid decays to char*.
Task-number: QTBUG-99122
Pick-to: 6.3 6.2
Change-Id: Ic5807f0161cd9f360baa07464988bc48b9679f64
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's deprecated in C++23. Just use an explicitly-aligned char array
directly, wrapped in a struct to avoid decays to char*.
Task-number: QTBUG-99122
Pick-to: 6.3 6.2
Change-Id: I802761c1af62efa6ffc006b07837a7deed1ea4cc
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Our previous approach of creating a union from individual special
integer bitfields leads to undefined values because only one member of a
union can be active at any given time. Compilers have finally caught up
with us on that and have started removing "no-op" writes to members.
The primary user of the special integer bitfield unions is
qv4compileddata_p.h in qtdeclarative. We want our on-disk format of
QML compilation units to be platform agnostic and space efficient.
Pick-to: 5.15 6.2 6.3
Task-number: QTBUG-99545
Change-Id: I24847bda2c364eb8ba75f074cde2a9bec25ced06
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
