2021-09-03 19:02:31 +02:00
|
|
|
ifndef COMPILER_FEATURES
|
|
|
|
|
COMPILER_FEATURES := $(shell ./detect-compiler $(CC))
|
|
|
|
|
endif
|
|
|
|
|
|
2018-04-14 21:19:45 +02:00
|
|
|
ifeq ($(filter no-error,$(DEVOPTS)),)
|
2019-02-22 15:41:27 +01:00
|
|
|
DEVELOPER_CFLAGS += -Werror
|
2020-10-31 23:22:08 +01:00
|
|
|
SPARSE_FLAGS += -Wsparse-error
|
2018-04-14 21:19:45 +02:00
|
|
|
endif
|
2021-09-29 05:19:40 +02:00
|
|
|
|
2021-09-03 19:02:31 +02:00
|
|
|
DEVELOPER_CFLAGS += -Wall
|
2021-09-03 19:02:32 +02:00
|
|
|
ifeq ($(filter no-pedantic,$(DEVOPTS)),)
|
2019-02-22 15:41:27 +01:00
|
|
|
DEVELOPER_CFLAGS += -pedantic
|
2021-09-29 05:19:40 +02:00
|
|
|
ifneq (($or $(filter gcc5,$(COMPILER_FEATURES)),$(filter clang4,$(COMPILER_FEATURES))),)
|
2021-09-03 19:02:32 +02:00
|
|
|
DEVELOPER_CFLAGS += -Wpedantic
|
2021-09-29 05:19:40 +02:00
|
|
|
ifneq ($(filter gcc10,$(COMPILER_FEATURES)),)
|
|
|
|
|
ifeq ($(uname_S),MINGW)
|
2021-09-03 19:02:32 +02:00
|
|
|
DEVELOPER_CFLAGS += -Wno-pedantic-ms-format
|
2021-09-03 19:02:31 +02:00
|
|
|
endif
|
2019-02-22 15:41:27 +01:00
|
|
|
endif
|
2021-09-29 05:19:40 +02:00
|
|
|
endif
|
|
|
|
|
endif
|
config.mak.dev: specify -std=gnu99 for gcc/clang
The point of DEVELOPER=1 is to turn up the warnings so we can catch
portability or correctness mistakes at the compiler level. But since
modern compilers tend to default to modern standards like gnu17, we
might miss warnings about older standards, even though we expect Git to
build with compilers that use them.
So it's helpful for developer builds to set the -std argument to our
lowest-common denominator. Traditionally this was c89, but since we're
moving to assuming c99 in 7bc341e21b (git-compat-util: add a test
balloon for C99 support, 2021-12-01) that seems like a good spot to
land. And as explained in that commit, we want "gnu99" because we still
want to take advantage of some extensions when they're available.
The new argument kicks in only for clang and gcc (which we know to
support "-std=" and "gnu" standards). And only for compiler versions
which default to a newer standard. That will avoid accidentally
silencing any build problems that non-developers would run into on older
compilers that default to c89.
My digging found that the default switched to gnu11 in gcc 5.1.0.
Clang's documentation is less clear, but has done so since at least
clang-7. So that's what I put in the conditional here. It's OK to err on
the side of not-enabling this for older compilers. Most developers (as
well as CI) are using much more recent versions, so any warnings will
eventually surface.
A concrete example is anonymous unions, which became legal in c11.
Without this patch, "gcc -pedantic" will not complain about them, but
will if we add in "-std=gnu99".
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-08 20:50:54 +01:00
|
|
|
|
Makefile: FreeBSD cannot do C99-or-below build
In "make DEVELOPER=YesPlease" builds, we try to help developers to
catch as many potential issues as they can by using -Wall and
turning compilation warnings into errors. In the same spirit, we
recently started adding -std=gnu99 to their CFLAGS, so that they can
notice when they accidentally used language features beyond C99.
It however turns out that FreeBSD 13.0 mistakenly uses C11 extension
in its system header files regardless of what __STDC_VERSION__ says,
which means that the platform (unless we tweak their system headers)
cannot be used for this purpose.
It seems that -std=gnu99 is only added conditionally even in today's
config.mak.dev, so it is fine if we dropped -std=gnu99 from there.
Which means that developers on FreeBSD cannot participate in vetting
use of features beyond C99, but there are developers on other
platforms who will, so it's not too bad.
We might want a more "fundamental" fix to make the platform capable
of taking -std=gnu99, like working around the use of unconditional
C11 extension in its system header files by supplying a set of
"replacement" definitions in our header files. We chose not to
pursue such an approach for two reasons at this point:
(1) The fix belongs to the FreeBSD project, not this project, and
such an upstream fix may happen hopefully in a not-too-distant
future.
(2) Fixing such a bug in system header files and working it around
can lead to unexpected breakages (other parts of their system
header files may not be expecting to see and do not work well
with our "replacement" definitions). This close to the final
release of this cycle, we have no time for that.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18 18:47:39 +01:00
|
|
|
ifneq ($(uname_S),FreeBSD)
|
config.mak.dev: specify -std=gnu99 for gcc/clang
The point of DEVELOPER=1 is to turn up the warnings so we can catch
portability or correctness mistakes at the compiler level. But since
modern compilers tend to default to modern standards like gnu17, we
might miss warnings about older standards, even though we expect Git to
build with compilers that use them.
So it's helpful for developer builds to set the -std argument to our
lowest-common denominator. Traditionally this was c89, but since we're
moving to assuming c99 in 7bc341e21b (git-compat-util: add a test
balloon for C99 support, 2021-12-01) that seems like a good spot to
land. And as explained in that commit, we want "gnu99" because we still
want to take advantage of some extensions when they're available.
The new argument kicks in only for clang and gcc (which we know to
support "-std=" and "gnu" standards). And only for compiler versions
which default to a newer standard. That will avoid accidentally
silencing any build problems that non-developers would run into on older
compilers that default to c89.
My digging found that the default switched to gnu11 in gcc 5.1.0.
Clang's documentation is less clear, but has done so since at least
clang-7. So that's what I put in the conditional here. It's OK to err on
the side of not-enabling this for older compilers. Most developers (as
well as CI) are using much more recent versions, so any warnings will
eventually surface.
A concrete example is anonymous unions, which became legal in c11.
Without this patch, "gcc -pedantic" will not complain about them, but
will if we add in "-std=gnu99".
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-08 20:50:54 +01:00
|
|
|
ifneq ($(or $(filter gcc6,$(COMPILER_FEATURES)),$(filter clang7,$(COMPILER_FEATURES))),)
|
|
|
|
|
DEVELOPER_CFLAGS += -std=gnu99
|
|
|
|
|
endif
|
Makefile: FreeBSD cannot do C99-or-below build
In "make DEVELOPER=YesPlease" builds, we try to help developers to
catch as many potential issues as they can by using -Wall and
turning compilation warnings into errors. In the same spirit, we
recently started adding -std=gnu99 to their CFLAGS, so that they can
notice when they accidentally used language features beyond C99.
It however turns out that FreeBSD 13.0 mistakenly uses C11 extension
in its system header files regardless of what __STDC_VERSION__ says,
which means that the platform (unless we tweak their system headers)
cannot be used for this purpose.
It seems that -std=gnu99 is only added conditionally even in today's
config.mak.dev, so it is fine if we dropped -std=gnu99 from there.
Which means that developers on FreeBSD cannot participate in vetting
use of features beyond C99, but there are developers on other
platforms who will, so it's not too bad.
We might want a more "fundamental" fix to make the platform capable
of taking -std=gnu99, like working around the use of unconditional
C11 extension in its system header files by supplying a set of
"replacement" definitions in our header files. We chose not to
pursue such an approach for two reasons at this point:
(1) The fix belongs to the FreeBSD project, not this project, and
such an upstream fix may happen hopefully in a not-too-distant
future.
(2) Fixing such a bug in system header files and working it around
can lead to unexpected breakages (other parts of their system
header files may not be expecting to see and do not work well
with our "replacement" definitions). This close to the final
release of this cycle, we have no time for that.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18 18:47:39 +01:00
|
|
|
else
|
|
|
|
|
# FreeBSD cannot limit to C99 because its system headers unconditionally
|
|
|
|
|
# rely on C11 features.
|
|
|
|
|
endif
|
config.mak.dev: specify -std=gnu99 for gcc/clang
The point of DEVELOPER=1 is to turn up the warnings so we can catch
portability or correctness mistakes at the compiler level. But since
modern compilers tend to default to modern standards like gnu17, we
might miss warnings about older standards, even though we expect Git to
build with compilers that use them.
So it's helpful for developer builds to set the -std argument to our
lowest-common denominator. Traditionally this was c89, but since we're
moving to assuming c99 in 7bc341e21b (git-compat-util: add a test
balloon for C99 support, 2021-12-01) that seems like a good spot to
land. And as explained in that commit, we want "gnu99" because we still
want to take advantage of some extensions when they're available.
The new argument kicks in only for clang and gcc (which we know to
support "-std=" and "gnu" standards). And only for compiler versions
which default to a newer standard. That will avoid accidentally
silencing any build problems that non-developers would run into on older
compilers that default to c89.
My digging found that the default switched to gnu11 in gcc 5.1.0.
Clang's documentation is less clear, but has done so since at least
clang-7. So that's what I put in the conditional here. It's OK to err on
the side of not-enabling this for older compilers. Most developers (as
well as CI) are using much more recent versions, so any warnings will
eventually surface.
A concrete example is anonymous unions, which became legal in c11.
Without this patch, "gcc -pedantic" will not complain about them, but
will if we add in "-std=gnu99".
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-08 20:50:54 +01:00
|
|
|
|
2019-02-22 15:41:27 +01:00
|
|
|
DEVELOPER_CFLAGS += -Wdeclaration-after-statement
|
|
|
|
|
DEVELOPER_CFLAGS += -Wformat-security
|
|
|
|
|
DEVELOPER_CFLAGS += -Wold-style-definition
|
|
|
|
|
DEVELOPER_CFLAGS += -Woverflow
|
|
|
|
|
DEVELOPER_CFLAGS += -Wpointer-arith
|
|
|
|
|
DEVELOPER_CFLAGS += -Wstrict-prototypes
|
|
|
|
|
DEVELOPER_CFLAGS += -Wunused
|
|
|
|
|
DEVELOPER_CFLAGS += -Wvla
|
config.mak.dev: build with -fno-common
It's an easy mistake to define a variable in a header with "int x;" when
you really meant to only declare the variable as "extern int x;"
instead. Clang and gcc will both allow this when building with
"-fcommon"; they put these "tentative definitions" in a common block
which the linker is able to resolve.
This is the default in clang and was the default in gcc until gcc-10,
since it helps some legacy code. However, we would prefer not to rely on
this because:
- using "extern" makes the intent more clear (so it's a style issue,
but it's one the compiler can help us catch)
- according to the gcc manpage, it may yield a speed and code size
penalty
So let's build explicitly with -fno-common when the DEVELOPER knob is
set, which will let developers using clang and older versions of gcc
notice these problems.
I didn't bother making this conditional on a particular version of gcc.
As far as I know, this option has been available forever in both gcc and
clang, so old versions don't need to avoid it. And we already expect gcc
and clang options throughout config.mak.dev, so it's unlikely anybody
setting the DEVELOPER knob is using anything else. It's a noop on
gcc-10, of course, but it's not worth trying to exclude it there.
Note that there's nothing to fix in the code; we already don't have any
issues here. But if you want to test the patch, you can add a bare "int
x;" into cache.h, which will cause the link step to fail.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-15 21:30:29 +02:00
|
|
|
DEVELOPER_CFLAGS += -fno-common
|
2018-04-14 21:19:44 +02:00
|
|
|
|
|
|
|
|
ifneq ($(filter clang4,$(COMPILER_FEATURES)),)
|
2019-02-22 15:41:27 +01:00
|
|
|
DEVELOPER_CFLAGS += -Wtautological-constant-out-of-range-compare
|
2018-04-14 21:19:44 +02:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifneq ($(or $(filter gcc6,$(COMPILER_FEATURES)),$(filter clang4,$(COMPILER_FEATURES))),)
|
2019-02-22 15:41:27 +01:00
|
|
|
DEVELOPER_CFLAGS += -Wextra
|
2018-04-14 21:19:44 +02:00
|
|
|
# if a function is public, there should be a prototype and the right
|
|
|
|
|
# header file should be included. If not, it should be static.
|
2019-02-22 15:41:27 +01:00
|
|
|
DEVELOPER_CFLAGS += -Wmissing-prototypes
|
2018-04-14 21:19:46 +02:00
|
|
|
ifeq ($(filter extra-all,$(DEVOPTS)),)
|
2018-04-14 21:19:44 +02:00
|
|
|
# These are disabled because we have these all over the place.
|
2019-02-22 15:41:27 +01:00
|
|
|
DEVELOPER_CFLAGS += -Wno-empty-body
|
|
|
|
|
DEVELOPER_CFLAGS += -Wno-missing-field-initializers
|
|
|
|
|
DEVELOPER_CFLAGS += -Wno-sign-compare
|
|
|
|
|
DEVELOPER_CFLAGS += -Wno-unused-parameter
|
2018-04-14 21:19:44 +02:00
|
|
|
endif
|
2018-04-14 21:19:46 +02:00
|
|
|
endif
|
2018-04-14 21:19:44 +02:00
|
|
|
|
|
|
|
|
# uninitialized warnings on gcc 4.9.2 in xdiff/xdiffi.c and config.c
|
|
|
|
|
# not worth fixing since newer compilers correctly stop complaining
|
|
|
|
|
ifneq ($(filter gcc4,$(COMPILER_FEATURES)),)
|
|
|
|
|
ifeq ($(filter gcc5,$(COMPILER_FEATURES)),)
|
2019-02-22 15:41:27 +01:00
|
|
|
DEVELOPER_CFLAGS += -Wno-uninitialized
|
2018-04-14 21:19:44 +02:00
|
|
|
endif
|
|
|
|
|
endif
|
perl: check for perl warnings while running tests
We set "use warnings" in most of our perl code to catch problems. But as
the name implies, warnings just emit a message to stderr and don't
otherwise affect the program. So our tests are quite likely to miss that
warnings are being spewed, as most of them do not look at stderr.
We could ask perl to make all warnings fatal, but this is likely
annoying for non-developers, who would rather have a running program
with a warning than something that refuses to work at all.
So instead, let's teach the perl code to respect an environment variable
(GIT_PERL_FATAL_WARNINGS) to increase the severity of the warnings. This
can be set for day-to-day running if people want to be really pedantic,
but the primary use is to trigger it within the test suite.
We could also trigger that for every test run, but likewise even the
tests failing may be annoying to distro builders, etc (just as -Werror
would be for compiling C code). So we'll tie it to a special test-mode
variable (GIT_TEST_PERL_FATAL_WARNINGS) that can be set in the
environment or as a Makefile knob, and we'll automatically turn the knob
when DEVELOPER=1 is set. That should give developers and CI the more
careful view without disrupting normal users or packagers.
Note that the mapping from the GIT_TEST_* form to the GIT_* form in
test-lib.sh is necessary even if they had the same name: the perl
scripts need it to be normalized to a perl truth value, and we also have
to make sure it's exported (we might have gotten it from the
environment, but we might also have gotten it from GIT-BUILD-OPTIONS
directly).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-22 05:24:00 +02:00
|
|
|
|
2022-04-16 01:13:41 +02:00
|
|
|
# https://bugzilla.redhat.com/show_bug.cgi?id=2075786
|
|
|
|
|
ifneq ($(filter gcc12,$(COMPILER_FEATURES)),)
|
|
|
|
|
DEVELOPER_CFLAGS += -Wno-error=stringop-overread
|
2022-04-16 01:13:42 +02:00
|
|
|
DEVELOPER_CFLAGS += -Wno-error=dangling-pointer
|
2022-04-16 01:13:41 +02:00
|
|
|
endif
|
|
|
|
|
|
perl: check for perl warnings while running tests
We set "use warnings" in most of our perl code to catch problems. But as
the name implies, warnings just emit a message to stderr and don't
otherwise affect the program. So our tests are quite likely to miss that
warnings are being spewed, as most of them do not look at stderr.
We could ask perl to make all warnings fatal, but this is likely
annoying for non-developers, who would rather have a running program
with a warning than something that refuses to work at all.
So instead, let's teach the perl code to respect an environment variable
(GIT_PERL_FATAL_WARNINGS) to increase the severity of the warnings. This
can be set for day-to-day running if people want to be really pedantic,
but the primary use is to trigger it within the test suite.
We could also trigger that for every test run, but likewise even the
tests failing may be annoying to distro builders, etc (just as -Werror
would be for compiling C code). So we'll tie it to a special test-mode
variable (GIT_TEST_PERL_FATAL_WARNINGS) that can be set in the
environment or as a Makefile knob, and we'll automatically turn the knob
when DEVELOPER=1 is set. That should give developers and CI the more
careful view without disrupting normal users or packagers.
Note that the mapping from the GIT_TEST_* form to the GIT_* form in
test-lib.sh is necessary even if they had the same name: the perl
scripts need it to be normalized to a perl truth value, and we also have
to make sure it's exported (we might have gotten it from the
environment, but we might also have gotten it from GIT-BUILD-OPTIONS
directly).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-22 05:24:00 +02:00
|
|
|
GIT_TEST_PERL_FATAL_WARNINGS = YesPlease
|