Macros can't include preprocessing directives in their expansion, both
in C and in C++; the behavior is undefined otherwise. In fact, there is
implementation divergence for object-like macros even between GCC/Clang
and MSVC [1], so relying on this is dangerous. For this reason,
compilers emit warnings.
However, function-like macros work as expected [2] on all three
compilers. The new preprocessor for MSVC will also align it to GCC/Clang
for object-like macros, but it's not enabled by default in any C++ mode
[3]. Changing that is out of scope for this patch.
Interestingly enough, Clang already does a distinction between
object-like macros (warns *unconditionally*) and function-like macros,
where the warning is only enabled by -Weverything or -pedantic. GCC
lacks this distinction, and enables the warning on -Wextra or -pedantic.
[4]
There's a major use case for expanding defined into a function-like
macro:test whether another macro is defined and, if so, if it has a
non-zero value.
This can be done with something like:
#define CHECK_HAS(X) (defined HAS_##X && HAS_##X)
#if CHECK_HAS(FOO)
These kind of checks are useful in qsimd_p.h, masm in qtdeclarative, and
maybe other places. Alas, they will trigger -Wexpansion-to-defined
warnings due to them being formally UB. We can suppress this warning
because we know that the compiler does the right thing, the testing of
which is point of *this* patch.
This has positive value over *not* doing this and risking people doing
this kind of checks instead:
#if HAS_FOO
(that is, the status quo) because the latter exposes people to bugs:
#if HAVE_FOO // whops! was HAS, not HAVE
#if HAS_FO0 // whops! typo
These bugs would be caught by -Wundef, that I'd like to enable, because
we've just had to fix a brown-paper-bag one. So the trade-off will be to
enable -Wundef, and ignore a "formally UB but works on all compilers"
warning, which I'm therefore suppressing.
Granted, in an ideal world, we would instead have HAS_FOO always
defined, to 0 if not enabled and to 1 if enabled. This would let us use
#if HAS_FOO
and have -Wundef warn in case of typos. However toolchains don't do this
for platform-specific macros, and there's still the issue of 3rd party
code. We could work around that by pre-defining our own QT_CHECK_HAS_FOO
to 0 / 1, but that would require centralizing the macros (we'd centrally
need to do define every possibility), which is what some of these macros
don't want to do by design.
[1] https://github.com/llvm/llvm-project/blob/main/clang/lib/Lex/PPExpressions.cpp#L167
[2] https://gcc.godbolt.org/z/hG3zzbhaj
[3] https://learn.microsoft.com/en-us/cpp/build/reference/zc-conformance?view=msvc-170
[4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118542
Task-number: QTBUG-132900
Change-Id: Ie4d28cfe91e6e9a8e7eedf92d5fa18913218817b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The flags are not valid for e.g. Swift
Pick-to: 6.7
Change-Id: Ie5b46dc9147d8c024e7e27712c7b8632abd727d9
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
MSVC also supports "-w" since at least 2015:
https: //learn.microsoft.com/en-us/cpp/build/reference/compiler-option-warning-level?view=msvc-140
Change-Id: If0775b1dd6e0785e2e42a25ed2b7f1346f7c345e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
- GHS compiler doesn't have -Wextra flag and it leads to huge count of warnings.
Pick-to: 6.2
Change-Id: Id2ba654a49fb163bebc75e3a22ecaa1895ecdbe8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The QT_COMPILE_OPTIONS_WARNINGS_OFF property can be set on targets
in order to disable adding the default compiler warnings flags.
This is useful when building 3rd party library code.
Change-Id: I9f58ca4543b5ea0d2051b7f94f0042d24c4e3a16
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Only has warnings for now
Next to come is the support for developer-build and enabling Werror
Change-Id: I8070dc06eb439c2a03007cce975c8147ff7e1582
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
