Because setObjectName() now takes a QAnyStringView, passing C string
literals is much more efficient than using QString::fromUtf8().
This patch only deals with setObjectName() as a known property,
probably from a name attribute. If the objectName property is set by a
<property> element (or so I assume), we still emit a
QString::fromUtf8(). Detecting objectName there would be too much
magic.
Besides, I haven't been able to find why sometimes there's a second
setObjectName call right after the first, when in the XML it seems all
kosher (name attribute and objectName <property> agreeing on the
content).
Change-Id: Icf07bad841ac735a9c744bbd955428ba15758089
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Use VERBATIM option to prepare the correct command line for the
add_custom_command. This especially sensitive when using build
directories with names containing special symbols, that cannot be
handled by shell correctly.
Change-Id: I51d7041cb806411135fd59bf6273c04a3c695443
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
And remove their uses.
[ChangeLog][QtCore][Deprecation Notice] Deprecated QString::count()
and QByteArray::count() that take no parameters, to avoid confusion
with the algorithm overloads of the same name. They can be replaced
by size() or length() methods.
Change-Id: I6541e3235ab58cf750d89568d66d3b1d9bbd4a04
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Relying on string manipulation leads to -Wredundant-parens warnings in
the best case, and to non-compiling code (when using typedefs) in the
worst case.
We can avoid both issues by simply generating code that uses
add_pointer, which takes care of reference types (even typedef'd ones),
and creates no warnings about parens (as we don't write any anymore).
Fixes: QTBUG-100915
Pick-to: 6.3 6.2
Change-Id: Ic5b1cbfda20d920d11f51beeb62e9479261d5f00
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
moc, qmake, rcc, and uic tests execute corresponding tools inside
the test executables. This adds dependencies explicitly, to execute
tests using _check targets, without the need to manually build
dependencies.
Pick-to: 6.3 6.2
Fixes: QTBUG-98576
Change-Id: I8b989276e21199b867591f7b0f6af9204695ac13
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The IGNORE directive was likely removed as an oversight
in the linked change.
This fixes the test to pass when bumping the Qt version.
Amends 9836dbd6ee
Change-Id: I497325d6d8b8b67cce7b0840bfb9bfa70d85fe73
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Change the minimum amount of buckets to be at least
128, ie. one full Span. This will simplify some assumptions
in the code.
Regeneration of rcc test-data needed because the extra buckets
causes the order of the keys to change.
Task-number: QTBUG-91739
Task-number: QTBUG-98436
Change-Id: Ic0c7da03570cc4c4e6aacc9645e536aec3667a98
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Like Q_NAMESPACE_EXPORT for Q_NAMESPACE, this variant of Q_GADGET
allows passing an export macro. This is useful to avoid exporting the
whole class just to get the staticMetaObject hidden therein exported.
Before anyone asks: No, we don't need Q_OBJECT_EXPORT, because QObject
subclasses, being polymorphic, always need to have a class-level
export macro (to export their vtable), but while that technique also
works for value classes (the Q_GADGET audience), it is not desirable
for them, because it makes inline functions exported in Windows debug
builds, which is not what we want, because it needlessly restricts
what you can to with the inline functions (e.g. remove).
[ChangeLog][QtCore] Added the Q_GADGET_EXPORT macro, which is like
Q_GADGET, but allows passing an export macro (like Q_NAMESPACE_EXPORT
for Q_NAMESPACE).
Fixes: QTBUG-55458
Change-Id: I546297de1e8aa45d83381991bcd3fbca61e1eef0
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Having all *deployqt tools in qtbase will allow us to couple deployment
support more tightly with the build system.
Change-Id: I299efdacfa6b66a303bb3996ff3ff84e723210a5
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
This hasn't worked for some time. It's not in our CI and I don't think
it was working at all. When I tried to build it, I ran into several
problems with C++17 and an Internal Compiler Error I did not have any
interest in working around.
After discussing with the Intel compiler team, it was decided that
fixing those issues in the old compiler is not going to happen. Instead,
their recommendation is to adopt the new LLVM-based compiler, which
the last commit added support for.
This commit does not remove qmake support for the old ICC. It's possible
someone is using qmake with a non-Qt6 project and ICC.
Change-Id: Icb2516126f674e7b8bb3fffd16ad6350ddbd49e5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
They return a pointer to the actual header, skipping the magic string.
This is done in preparation for the header located in an ELF note, which
won't have the magic.
Change-Id: I3eb1bd30e0124f89a052fffd16a8229bec2ad588
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The .qtmetadata section is already suppressed for static plugins, but we
carried this unnecessary magic string. For library file formats where we
don't have a scanner (Windows COFF PE), a library that linked multiple
static plugins could end up with multiple metadata found.
We can't suppress the header because the version of moc could be
different to the version of Qt, so we need to read the header version
too. Right now, the version isn't output by moc (all the logic is in
qplugin.h), but this could change again in the future. In any case, 4
extra bytes are not a big deal, so the header stays.
Change-Id: I3eb1bd30e0124f89a052fffd16a82088d8303081
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
tests/auto/tools/moc/CMakeFiles/tst_moc.dir/tst_moc.cpp.o: in function `tst_Moc::os9Newline()':
qtbase/tests/auto/tools/moc/tst_moc.cpp:1225: undefined reference to `Os9Newlines::staticMetaObject'
tests/auto/tools/moc/CMakeFiles/tst_moc.dir/tst_moc.cpp.o: in function `tst_Moc::winNewline()':
qtbase/tests/auto/tools/moc/tst_moc.cpp:1239: undefined reference to `WinNewlines::staticMetaObject'
Pick-to: 6.2
Change-Id: I629d67c1190e09b26dc09e41cb7170cb0eadf1cb
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Hopefully we won't need it but let's have it still at least for
consistency
Change-Id: I72289e65e5e5613174ad4d98cf8d614f9caae8e6
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The solution in d3ed7dac8a was needlessly
complicated, and broke a valid use case.
The issue of no identifier being available to parse after the include
has been processed can instead be solved by moving the test for the
closing brace after the include processing.
Fixes: QTBUG-94790
Pick-to: 6.2 6.1 5.15
Change-Id: Ieec4b89e1d117637f11479e8bddc4060f93da43d
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The QtTest best practices documentations recommends using output
mechanisms such as qDebug() and qWarning() for diagnostic messages,
and this is also what most of our own tests do.
The QWARN() macro and corresponding internal QTest::qWarn() function
was added when QtTest was first implemented, but was likely meant as
an internal implementation detail, like its cousin QTestLog::info(),
which does not have any corresponding macro.
This theory is backed by our own QtTest self-test (tst_silent)
describing the output from QWARN() as "an internal testlib warning".
The only difference between QWARN() and qWarning(), besides the much
richer feature set of the latter, is that qWarning() will not pass
on file and line number information in release mode, but QWARN() will.
This is an acceptable loss of functionality, considering that the user
can override this behavior by defining QT_MESSAGELOGCONTEXT.
[ChangeLog][QtTest] QWARN() has been deprecated in favor of qWarning()
Pick-to: 6.2
Change-Id: I5a2431ce48c47392244560dd520953b9fc735c85
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Before this change, next() was the only way to advance the iterator,
whether the caller was ultimately interested in just the filePath()
(good) or not (bad luck, had to call .fileInfo()).
Add a new function, nextFileInfo(), with returns fileInfo() instead.
Incidentally, the returned object has already been constructed as part
of advance()ing the iterator, so the new function is faster than
next() even if the result is ignored, because we're not calculating a
QString result the caller may not be interested in.
Use the new function around the code.
Fix a couple of cases of next(); fileInfo().filePath() (just use
next()'s return value) as a drive-by.
[ChangeLog][QtCore][QDirIterator] Added nextFileInfo(), which is like
next(), but returns fileInfo() instead of filePath().
Change-Id: I601220575961169b44139fc55b9eae6c3197afb4
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
There's a chance that this would be used in some macro, so why not test
that this thing works in general (especially since it actually works)
Change-Id: Ib9d91fbd17cf16675ae89a99f010dacc5d30967a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Triggered by API review in Gerrit patch 355960.
Task-number: QTBUG-94407
Pick-to: 6.2
Change-Id: I7cafc1cc9d4b929040b53c6bf92c91d73c3b39f2
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The relevant test is conducted by tst_Moc::warnOnVirtualSignal(),
added in 2009, <quote>
Fix Warning saying that signal cannot be made virtual
The test for virtual signal did not work.
But we cannot make an error right now or it might break existing code
(exemple in task 210879)
</quote> but without removing the #include, so we do still get a
warning about that when building tst_moc.
Pick-to: 6.2 6.1 5.15
Change-Id: I5ea18058f22bbd483d1ff18b0ca7b360f6674ed9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Needed for QML compiler to know property index of C++ type at
compile time without going through QMetaObject::indexOfProperty
Change-Id: I404e71d6071d36812661df17d12b879a8dcbd146
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Use class WriteIncludesBase and store classes encountered in a
per-module hash (Qt/custom widgets). Write out only the required
classes.
Add --star-import as a fallback should the change cause issues.
Task-number: PYSIDE-1404
Change-Id: Ic50e26758ddd0f2f8aebbce470d32a36fb09a2c4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
The BASE argument of qt_add_resources now denotes the root point of the
alias of the file. Before, BASE was merely prepended to every file that
got passed to qt_add_resources.
Old behavior:
qt_add_resources(app "images"
PREFIX "/"
BASE "../shared"
FILES "images/button.png")
Alias is "../shared/images/button.png", and pro2cmake generated
QT_RESOURCE_ALIAS assignments to fix this.
New behavior:
qt_add_resources(app "images"
PREFIX "/"
BASE "../shared"
FILES "../shared/images/button.png")
The alias is "images/button.png". No extra QT_RESOURCE_ALIAS assignment
is needed.
The new behavior is in effect for user projects and for Qt repositories
that define QT_USE_FIXED_QT_ADD_RESOURCE_BASE. Qt repositories will be
ported one by one to this new behavior. Then the old code path can be
removed.
Pick-to: 6.1
Task-number: QTBUG-86726
Change-Id: Ib895edd4df8e97b54badadd9a1c34408beff131f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We only need to the location of certain paths for the test. For that,
qtpaths is sufficient.
Change-Id: I5af0d56b548629edc48949150ed8fbd408b617a6
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Although the code is never executed compilers still throw a warning
because it's compiled.
Amends 12b8283f89
Pick-to: 5.15 6.1
Change-Id: Ib790d4bcb33c4b9f2a55a784b852275b59debde9
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We deliberately expose moc to warning-worthy C++, but we don't want the
compiler warnings coming from those.
Change-Id: I09c36d7c8bfbb88f7bde61fa7bcc52a5adde81da
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
[ChangeLog][Build System] Tools that are called by the build system and
are unlikely to be called by the user are now installed to the libexec
directory.
This is a step towards easier co-installability of different Qt
versions.
Pick-to: 6.1
Task-number: QTBUG-88791
Change-Id: Id19575b5ba27795f7715e4ea6a09391b26dd4942
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
With the updated QEMU and toolchain, these tests now pass.
Change-Id: Icb74562a0e6422cd4564f63db991aa431e0e3119
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Those serve no purpose anymore, now that the .pro files are gone.
Task-number: QTBUG-88742
Change-Id: I39943327b8c9871785b58e9973e4e7602371793e
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Remove the qmake project files for most of Qt.
Leave the qmake project files for examples, because we still test those
in the CI to ensure qmake does not regress.
Also leave the qmake project files for utils and other minor parts that
lack CMake project files.
Task-number: QTBUG-88742
Change-Id: I6cdf059e6204816f617f9624f3ea9822703f73cc
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Complete search and replace of QtTest and QtTest/QtTest with QTest, as
QtTest includes the whole module. Replace all such instances with
correct header includes. See Jira task for more discussion.
Fixes: QTBUG-88831
Change-Id: I981cfae18a1cabcabcabee376016b086d9d01f44
Pick-to: 6.0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Apparently some library definitions went overboard, link them directly.
Pick-to: 6.0
Change-Id: I009737f7e3edff5619241b700a627dc4e25e6018
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Just like it was done in the .pro file.
Pick-to: 6.0
Change-Id: I7def52127f4bab6f0ef490ac7eee2de2da479352
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
gcc, clang, and MSVC all use lowercase "warning:", "error:" and
"note:". Follow that standard.
Also, include a column number; just print 1, as the Symbol doesn't
give us a column number, and searching backwards for a newline seems
overkill.
This fixes IDE integrations that parse compiler output using regular
expressions.
The test checks for moc output, but most tests were so far only
running on Linux systems. Expand this to Unix for most tests, which
then includes macOS.
Change-Id: I0a6151cc0dc50e52ca72ff8048a45213aebdb3a8
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
A dependency was missing, causing qduplicatetracker_p not to be found.
Change-Id: I4076d6cf82d804354731c357bcdbfd03c3d42142
Reviewed-by: David Faure <david.faure@kdab.com>
The existing logic broke down when we reentered the enumerator parsing
loop, and encountered a INCLUDE_MOC_END token in the first handleInclude
call. Fix this by restarting the loop in that case.
Amends d8a2456fbf.
Fixes: QTBUG-88125
Pick-to: 5.15
Change-Id: I87acaa986a81de53730eddc40bc7d48c15328aba
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
When cross-building Qt with CMake to target qemu configs in the CI,
we specify the -DQT_BUILD_TOOLS_WHEN_CROSSCOMPILING=ON option to also
cross-build tools (like qmake).
In this case, $prefix/bin/qmake points to the cross-compiled qmake,
and the shell script that wraps the host qmake is called
$prefix/bin/host-qmake instead.
In such a scenario, tst_qmake ends up running the cross-compiled
qmake, which thinks that it's being run on device (via user-space
qemu emulation) and doesn't specify the sysroot when computing include
paths, link paths, etc. This causes the test building to fail in
various ways.
To fix the test, check for the existence of the host-qmake wrapper,
and if it exsists use it instead.
Task-number: QTBUG-86053
Change-Id: Iaa4afdf11b17f23abef873dd15b1ed950126ab8c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Use a simpler constexpr to generate type name on gcc This
works around an ICE on gcc in release mode when compiling
with PCH enabled. As the type we're getting from Q_FUNC_INFO is
already in a somewhat normalized form, this requires significanlty
less processing and esp. not a recursive constexpr method which
I suspect triggers the ICE.
Fix integer type conversions to also properly normalize long long
values (to q(u)longlong. Make sure the mapping also works on
MSVC, where long long types get mapped to __int64. Also, normalize
unsigned short and unsigned char to ushort and uchar, respectively, to
follow the convention set by uint and ulong.
Add some test cases to verify the mappings.
Change-Id: I3dec5764450bf22ab6f066597803c3f46c2cd5ac
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This time based on grepping to also include documentation, tests and
examples previously missed by the automatic tool.
Change-Id: Ied1703f4bcc470fbc275f759ed5b7c588a5c4e9f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
