2022-07-05 13:26:52 +02:00
|
|
|
# Copyright (C) 2022 The Qt Company Ltd.
|
2022-08-19 15:21:34 +02:00
|
|
|
# SPDX-License-Identifier: BSD-3-Clause
|
2022-07-05 13:26:52 +02:00
|
|
|
|
2021-11-02 13:59:37 +01:00
|
|
|
# Enable compiler warnings by default. All compilers except MSVC support -Wall -Wextra
|
|
|
|
|
#
|
|
|
|
|
# You can disable the warnings for specific targets (for instance containing 3rd party code)
|
|
|
|
|
# by calling qt_disable_warnings(target). This will set the QT_COMPILE_OPTIONS_DISABLE_WARNINGS
|
|
|
|
|
# property checked below, and is equivalent to qmake's CONFIG += warn_off.
|
2020-02-24 12:38:55 +01:00
|
|
|
|
|
|
|
|
set(_qt_compiler_warning_flags_on "")
|
2023-10-07 14:07:19 +08:00
|
|
|
set(_qt_compiler_warning_flags_off -w)
|
2020-02-24 12:38:55 +01:00
|
|
|
|
2019-02-19 17:37:30 +01:00
|
|
|
if (MSVC)
|
2020-02-24 12:38:55 +01:00
|
|
|
list(APPEND _qt_compiler_warning_flags_on /W3)
|
Test that macro expansion to `defined` actually works
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>
2025-01-18 12:45:10 +01:00
|
|
|
# MSVC warns about macros expanding to `defined` when using the
|
|
|
|
|
# new preprocessor (so far, default for C11 code, but not C++).
|
|
|
|
|
# Suppress the warning, see also the comment below for GCC.
|
|
|
|
|
list(APPEND _qt_compiler_warning_flags_on /wd5105)
|
2019-02-19 17:37:30 +01:00
|
|
|
else()
|
2021-11-17 12:26:50 +02:00
|
|
|
if(CMAKE_CXX_COMPILER_ID STREQUAL "GHS") # There is no -Wextra flag for GHS compiler.
|
|
|
|
|
list(APPEND _qt_compiler_warning_flags_on -Wall)
|
|
|
|
|
else()
|
|
|
|
|
list(APPEND _qt_compiler_warning_flags_on -Wall -Wextra)
|
|
|
|
|
endif()
|
Test that macro expansion to `defined` actually works
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>
2025-01-18 12:45:10 +01:00
|
|
|
if (CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
|
|
|
|
|
if (CMAKE_CXX_COMPILER_VERSION VERSION_LESS "17.0.0")
|
|
|
|
|
# GCC warns if a macro is expanded to `defined`, but doesn't
|
|
|
|
|
# differentiate between object-like and function-like macros.
|
|
|
|
|
# The latter generally work everywhere. We don't have fine-grained
|
|
|
|
|
# control, so disable the warning (tst_qglobal tests for this
|
|
|
|
|
# behavior.)
|
|
|
|
|
# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118542
|
|
|
|
|
list(APPEND _qt_compiler_warning_flags_on -Wno-expansion-to-defined)
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
2019-02-19 17:37:30 +01:00
|
|
|
endif()
|
2020-02-24 12:38:55 +01:00
|
|
|
|
|
|
|
|
set(_qt_compiler_warning_flags_condition
|
|
|
|
|
"$<BOOL:$<TARGET_PROPERTY:QT_COMPILE_OPTIONS_DISABLE_WARNINGS>>")
|
|
|
|
|
set(_qt_compiler_warning_flags_genex
|
|
|
|
|
"$<IF:${_qt_compiler_warning_flags_condition},${_qt_compiler_warning_flags_off},${_qt_compiler_warning_flags_on}>")
|
|
|
|
|
|
2024-04-05 14:46:55 +02:00
|
|
|
set(_qt_compiler_warning_flags_language_condition
|
|
|
|
|
"$<COMPILE_LANGUAGE:CXX,C,OBJC,OBJCXX>")
|
|
|
|
|
set(_qt_compiler_warning_flags_language_conditional_genex
|
|
|
|
|
"$<${_qt_compiler_warning_flags_language_condition}:${_qt_compiler_warning_flags_genex}>")
|
|
|
|
|
|
|
|
|
|
|
2020-02-24 12:38:55 +01:00
|
|
|
# Need to replace semicolons so that the list is not wrongly expanded in the add_compile_options
|
|
|
|
|
# call.
|
|
|
|
|
string(REPLACE ";" "$<SEMICOLON>"
|
2024-04-05 14:46:55 +02:00
|
|
|
_qt_compiler_warning_flags_language_conditional_genex
|
|
|
|
|
"${_qt_compiler_warning_flags_language_conditional_genex}")
|
|
|
|
|
add_compile_options(${_qt_compiler_warning_flags_language_conditional_genex})
|
