This is legacy behavior from Qt 3, before we had QFlags and before
QVariant could support user types. I cannot find any instance of a
getter returning an integer in current Qt or Qt Creator code. And note
this only compiles if the flags type with Q_FLAG - not Q_ENUM.
The content is wrapped as Qt 6.x only so it can be removed in Qt
7.0. The deprecation warning will come in a later commit, for 6.9.
Change-Id: Ie3ddd8025e3b4387866efffd8e8d46c3daa0dff2
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 939f7f56227e65c9797d17640a7b9c29166efc44)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
We want to be able to index into the metaobject from code generated by
qmltyperegistrar. And we don't want to rely on some implicit promise
that certain methods are in the "right" order in the output. This is
similar to what we've done with properties.
Change-Id: I8d97b65598338fcff57c6b0866708232066c94cb
Task-number: QTBUG-127442
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 484e72a1074279dca1253ae07515461ad231de3c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Checking the underlying type's metatype is checking through a QMetaType
feature, not moc's functionality. And QMetaType currently always returns
the metatype for int for all QFlags types.
Change-Id: I8a96935cf6c742259c9dfffd17e9791608e38b6e
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
(cherry picked from commit 46b73b1ef37e22af23bfce992f41498c6409df3a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QCOMPARE is (actual, expected).
Take the opportunity to test out-of-range returns from QMetaEnum too.
Change-Id: I8a96935cf6c742259c9dfffd17e9575a6d4cf90a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit e3e44e2294c06f243838dfa28ec4f350c5e6ffbb)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Amend moc's JSON output with line information for the classes we find.
Task-number: QTBUG-119143
Change-Id: I821f0c30a56ed992cb9c6173f1e28ace1f26e9cf
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
Reviewed-by: Semih Yavuz <semih.yavuz@qt.io>
(cherry picked from commit 1d4533bd5fac54cb5555f03ff08e9085fa533c16)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When passing -use-debug-libs to macdeployqt it will only consider plugins
that end with _debug.dylib, which is not the case for single-configuration
framework builds as of d3be87ff1d558f05309b1f29f7e71f291498584f.
When not passing -use-debug-libs macdeployqt will use whatever library
it finds, both suffixed and not, so the only case where we need to
explicitly make it choose one is when we have a debug-and-release
build of Qt. Otherwise we can leave macdeployqt to choose the right
one.
Change-Id: Ic438da9f21c3090f0d57ce615bc0c0969b9a600d
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
(cherry picked from commit 60550f8acc4f9d742f6ef7cb027f0ed3e2d5e42a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
GCC doesn't have a specific warning flag for this warning, so we can't
add a GCC case to the existing Clang suppression in the header.
Hovever, the issue can be fixed by including the moc file into
tst_moc.cpp, so that the compiler sees the definition of the inline
signal provided by the said moc file. This means we can also drop the
Clang warning suppressions.
To prevent duplicate definition linker errors, remove the header file
from JSON_FILES, and the forced separate compilation that entails.
I'm pretty sure that some cmake magic could preserve the JSON test
coverage, but a) the file doesn't emit anything special in its json
(certainly nothing about the inline'ness of the signals) and b) the
presence of mySlot() and mySignal() as slot and signal on these
classes is already tested by singleFunctionKeywordSignalAndSlot().
Amends the start of the public history, but not picking back far,
because a) a prequel commit to this commit wasn't picked further,
either, and b) this has been such a long-standing issue that it's
clear no-one cares and so it's just not worth the risk, however small
that may be, to backport.
On GCC, the only remaining warnings thrown by tst_moc are now
moc-generated ones.
Task-number: QTBUG-119042
Change-Id: Icde1eee6c97bd48d72e15461b6ec80c50c044eaa
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit b1b3af02c0fb8084d2eb984b1f7ae68f1861f9a4)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Suppress the warning. Found that moc doesn't like QT_WARNING macros in
Q_SIGNALS section and filed QTBUG-126395 to track the issue.
Amends the start of the public history, but not picking back far,
since older GCC could reject the suppression, and it's such a
long-standing issue that fixing it in LTS branches is not worth the
risk of breaking compilation.
Task-number: QTBUG-119042
Task-number: QTBUG-126395
Change-Id: I15ba9ed3b83cce0f4c2a1536317e5167d56f3a57
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 4111059b2ee3818ab68033198fb1dd057e6d09eb)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
We rely on a valid Xcode (command line tools) installation to run qmake.
Change-Id: I8d6746942507680dd585a41f32cbe4e4d34822e4
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 06b33134b38ffabdf0c0d80c2c3b9581294ff715)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
That is printed at the top of the file and we've used it for the
copyright inside Qt, so just declare an alias.
[ChangeLog][uic] The Qt UI Compiler now accepts a <legal> XML tag to
indicate the copyright of the UI file and other legal terms of use. The
text of this tag will be emitted in the generated code. This tag is an
alias to <comment>.
Change-Id: If3345151ddf84c43a4f1fffd17d15ab77412e289
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
According to gnu.org[1]
> When a file is automatically generated from some other file in the
> distribution, it is useful for the automatic procedure to copy the
> copyright notice and permission notice of the file it is generated
> from, if possible.
This commit allows us to add copyright notices to the .qrc files
themselves and additionally have that be output into the generated .rcc
(of which we have a few committed to the repository)
[ChangeLog][rcc] The Qt Resource Compiler now accepts a <legal> XML tag
inside the main <RCC> entry, which can be used to document the copyright
of the resource file itself and other terms of use (even though the file
is probably created by a tool like Qt Creator's resource editor). The
text of this copyright will be emitted in the generated C++ or Python
source code.
[1] https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html
Change-Id: If05cb740b64f42eba21efffd17d00417433f1ee9
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
For those files, reuse fails to process the copyright and licensing information. The information is written to .reuse/dep5 file and reuse is told to ignore what is in the file.
Task-number: QTBUG-124453
Change-Id: If593c713026d9d349055cb6e8e73500966a05d9b
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
While <DIGIT>+<Character> is not a valid identifier by itself in the C++
language, it might become one when using it with the token pasting
operator.
This risks confusing some number literals with suffix as Identifiers,
but those are currently not supported anyway, so this shouldn't break
anything that is currently working.
Fixes: QTBUG-87219
Fixes: QTBUG-124288
Pick-to: 6.7
Change-Id: If73255cc0e6649bc90c52b1d177aac8ff975ae69
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Code that sets a test function up should not be fallible, or should be
designed to log the failure. In tst_moc this is not the case --
QFile::open is called from within a nested lambda. If that fails, print
the error and return an empty optional.
Task-number: QTBUG-123623
Change-Id: I8372a6ac7dc22e68d145fa2215fe04ba682ac81b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
qOverload was used only for ambiguous signals and slots with no
arguments. Connections to ambiguous slots made in widget designer's
signal/slot editor, lead to an unresolved ambiguity when compiling
the generated code in ui_xxx.h. One example is QLabel::setNum(), which
can either take a double or an int.
Always using qOverload is not an alternative, because signatures are
normalised. E.g. const QString & / QString can't be distinguished.
Add a map with all ambiguous signals and slots to customwidgetsinfo.cpp.
Hardcode the map, because uic lives in QtCore and can't access meta
objects of gui/widget classes.
Use this map in isAmbiguousSignal() and add isAmbiguousSlot().
Change OverloadUse enum into an enum class in language.cpp. Change
enum values to reflect the new condition for slots to use qOverload.
Rename existing enum values and remove default argument in
language::formatMemberFnPtr() to improve code readability.
Apply const T& syntax for all types starting with Q, except QSize and
QPoint.
Revert 94c16517b3, which was a hack
forcing for QLCDNumber::display() to a string based connection.
Add a new baseline to tst_uic, to test the above.
Fixes: QTBUG-93413
Task-number: QTBUG-124241
Pick-to: 6.7 6.6 6.5 6.2
Change-Id: I49ccc1688cfc08970cce3e56adf18e5ac49a77e1
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Split out some helpers to write the theme code with path fallback
checking for the enum case (identified by a fully qualified icon) or
the old XDG/filename case.
Task-number: QTBUG-121823
Pick-to: 6.7
Change-Id: If2755483ab899f04e372cf95443f7e03970f6e7f
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Inline namespaces serve the purpose for which the original
-qtnamespace option was added and allow for macro simplification (no
need for any using directives). This makes it possible to use
namespaced builds of Qt also for Qt for Python and similar use cases
which have issues with the additional namespace.
[ChangeLog][QtCore] It is now possible to use an inline namespace for
-qtnamespace (option -qtinlinenamespace).
Task-number: PYSIDE-2590
Change-Id: Ia0cecf041321933a2e02d1fd8ae0e9cda699cd1e
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
A macro to mark tech preview APIs, in order to make header reviews
easier:
* newly introduced TP APIs are clearly marked as such;
* an API that leaves TP and becomes stable requires to change the
header, and not just the documentation (and therefore will again
appear in the header review).
The idea is to use this macro as if it were a C++ attribute.
It can't actually be an attribute, because we want to use it to tag
e.g. macro expansions (like Q_PROPERTY).
Change-Id: I05c5a91a4fa5bedfbd1c6146d4dc00e1d1d28628
Pick-to: 6.7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
According to QUIP-18 [1], all tests file should be
LicenseRef-Qt-Commercial OR GPL-3.0-only
[1]: https://contribute.qt-project.org/quips/18
Pick-to: 6.7
Task-number: QTBUG-121787
Change-Id: I9657df5d660820e56c96d511ea49d321c54682e8
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Tooling can then use this information to find the correct base class,
even absent C++ scoping information.
Pick-to: 6.7 6.6 6.5
Task-number: QTBUG-101141
Change-Id: I5350da8d2d9aaf5ec86027357131ebac1eb50372
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The moc generated code does a sanity check that NOTIFY signals actually
exist in the parent class when they cannot be found in the class moc
currently runs on.
The logic there was however too simplistic, and couldn't deal with
signals taking a parameter.
Fix this, and take the opportunity to use a proper static_assert instead
of generating a "normal" compile error.
We do not do any checks for the presence of QPrivateSignal, as the whole
point of QPrivateSignal is that it should be private (and not e.g.
protected).
Moreover, we adjust QMetaProperty::notifySignalIndex to take
single-argument notify methods into consideration as well when
encontering an unresolved notify index.
Fixes: QTBUG-115989
Pick-to: 6.7
Change-Id: I8a056a15777f3132691e207b4b9ab6c2c9b2126d
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
While the code that checked that exitCode() == 0 was still consistent
between all the callers, when it comes to checking stderr, there were
several competing implementations, incl. checking the exitCode and
dumping stderr to qDebug(), and using QCOMPARE to QByteArray(),
presumably in order to get more detailed output on error. Alas,
QCOMPARE's toString() truncates output pretty early, making it
impossible to see what's going on on failure.
So write a small macro that checks the exitCode _after_ it checked
that stderr was empty (printing it in full if it was not), so we
consistently get the error message instead of a truncated version, or
just "exitCode() != 0" without further details.
Pick-to: 6.7 6.6 6.5 6.2 5.15
Change-Id: Ic8547fda3b02c645901962887c6ed7aad01f6ea4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
They have nothing to do with each other, so give QTypeRevision its own
header and implementation file instead of piggy-backing on
QVersionNumber's.
Picking back to current LTS to incur the merge conflict only once, not
per (expected) follow-up change.
Amends ed080c64ae.
Pick-to: 6.7 6.6 6.5
Change-Id: I2fa5d0e68f95864126bc95e3d8154134eee85553
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
We don't execute this test at all for Boot2Qt anymore.
Task-number: QTBUG-90545
Change-Id: I2f42a7612f5cd61a72a588b95ca043ac03d03697
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Explicitly register QtDBus-specific metatypes before attempting
to generate output. This fixes a bug when types like QDBusObjectPath
are sometimes ignored by this tool. Export QDBusMetaTypeId::init()
for that reason. Add a regression test to tst_qdbuscpp2xml.
Fixes: QTBUG-34550
Change-Id: I16faa79a794d09a26bad45e18730379681a20b50
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Ignore the 'inline' in case of nested namespace with another
nested inline namespace.
Amends 5222df2be7
Fixes: QTBUG-117765
Pick-to: 6.6 6.5
Change-Id: I87f2649606f63c818f225f8cc5ec914920763c5f
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This means checks have to be rewritten using endsWith().
It mainly affects the QSizePolicy handling whose values originate from
different sources, including numbers. To address this, refactor the
code to deal with unqualified enum value names and introduce a helper
function that fully qualifies the enumeration when writing out.
Pick-to: 6.6 6.5
Task-number: PYSIDE-2492
Task-number: PYSIDE-1735
Task-number: QTBUG-118473
Change-Id: Iccbb884777aa9c696fbf48f9d7329353ef945b0f
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
proEval(), proParser(): the loop was iterating over a temporary so it
couldn't have changed it. Hold the container in a const auto variable
and use ranged-for.
formatValue(): iterating over a const QList& parameter, and the container
isn't changed at the call sites during iterating, so Q_FOREACH wasn't
needed to beging with. Use ranged-for instead.
Task-number: QTBUG-115839
Change-Id: Idabe0bbd84b5bcc86cef275f80497651353a4d9e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
systemEnvironment(): the loop was iterating over a temporary; hold the
temporary in a local const auto variable and use ranged-for.
runCommand(): the container is a const&, the loop doesn't change the
container and the containers the method is called on aren't changed
during iteration.
Task-number: QTBUG-115839
Change-Id: I6687e5ff64ff8c2fa26e34abf4044b98718e65d4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
specifyMetaTagsFromCmdline(): the loop was iterating over a temporary so
it couldn't have modified it; hold it with a const auto variable and use
ranged-for.
relatedMetaObjectsNameConflict_data(): make the container const and port
to ranged-for.
Task-number: QTBUG-115839
Change-Id: I6a5afdf0e5a3dd47818da0025fbbeacd05335b39
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The density of Q_FOREACH uses in this and some other modules is still
extremely high, too high for anyone to tackle in a short amount of
time. Even if they're not concentrated in just a few TUs, we need to
make progress on a global QT_NO_FOREACH default, so grab the nettle
and stick to our strategy:
Mark the whole of Qt with QT_NO_FOREACH, to prevent new uses from
creeping in, and whitelist the affected TUs by #undef'ing
QT_NO_FOREACH locally, at the top of each file. For TUs that are part
of a larger executable, this requires these files to be compiled
separately, so add them to NO_PCH_SOURCES (which implies
NO_UNITY_BUILD_SOURCES, too).
In tst_qglobal.cpp and tst_qcollections.cpp change the comment on the
#undef QT_NO_FOREACH to indicate that these actually test the macro.
Task-number: QTBUG-115839
Change-Id: Iecc444eb7d43d7e4d037f6e155abe0e14a00a5d6
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Amends f2f8820073.
I have no idea how this went through the CI, but assigning to a const
variable cannot possibly compile.
Reported-by: Axel Spoerl <axel.spoerl@qt.io>
Pick-to: 6.6 6.5
Task-nubmber: QTBUG-115839
Change-Id: I0f22dcd5ab691f92880ea3c6446aedca53df0721
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
By actually registering them.
Commit 850d850c5a changed from
qMetaTypeId<QDBusArgument>() to QMetaType::fromType<QDBusArgument>() and
in Qt 6, fromType() does not register the type with the database. That
means the lines became runtime no-ops at that time or during the
QMetaType updates since 6.0. All they did was instantiate the C++ inline
variable.
The testing also detected we didn't register QList<QDBusVariant> as an
alias for the "av" signature. I'm not entirely sure you're allowed to
use this because QtDBus does not like re-registration of the built-in
types, and "av" is already assigned to QVariantList. This is no trouble
for the parser, anyway.
Minor change to qdbuscpp2xml to allow reading from stdin, so we don't
have to create temporary files.
Pick-to: 6.5 6.6
Fixes: QTBUG-115964
Change-Id: I80612a7d275c41f1baf0fffd177a14925e7d23ac
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
Strictly speaking, we don't need the *bus*, only libdbus-1, but some
machines in our CI appear to be misconfigured somehow. I don't
understand how they can both have and not have this library in the same
run.
Pick-to: 6.5 6.6
Change-Id: I80612a7d275c41f1baf0fffd177a66a04951948c
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
All of these fall into the trivial category: loops over (readily made)
const local containers. As such, they cannot possibly depend on the
safety copy that Q_FOREACH performs, so are safe to port as-is to
ranged for loops.
There may be more where these came from, but these were the ones that
stood out as immediately obvious when scanning the 100s of uses in
qtbase, so I preferred to directly fix them over white-listing their
files with QT_NO_FOREACH (which still may be necessary for some files,
as this patch may not port all uses in that file).
Pick-to: 6.6 6.5
Task-nubmber: QTBUG-115839
Change-Id: I7b7893bec8254f902660dac24167113aca855029
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Most of these are of trivial kind (loops over const locals).
The one that isn't, in cleanupTestCase(), is, however, also simple:
it's a loop over a local, too, but it would be too much churn to
change the initialization to make the container const, and the loop
body clearly doesn't modify the container, so just go with the
std::as_const() pattern here.
Task-number: QTBUG-115839
Pick-to: 6.6 6.5
Change-Id: I188a78ea67a63be2d50a81fea431e5ea9f2783cb
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
QList rather pointlessly has a startsWith() function, which means this
code compiled. But the code makes no sense: it tests the same
condition over and over again, so I'm assuming that it should be
path.startsWith() and not path_s_.startsWith().
Amends 3f56950862, but that just
imported the code from qttools. I didn't check whether the bug was
present there, already.
Pick-to: 6.6 6.5
Change-Id: I98a4bbfe0400700655a5c2137f7a976a835a8d28
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Thiago Macieira
Jani Heikkinen
Ulf Hermann
Friedemann Kleint
Fabian Kosmale
Tor Arne Vestbø
Marc Mutz
Joerg Bornemann
Lucie Gérard
Giuseppe D'Angelo
Axel Spoerl
hjk
Ievgenii Meshcheriakov
Ahmad Samir