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
|
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
|
|
|
|
|
|
|
|
GIT_TEST_PERL_FATAL_WARNINGS = YesPlease
|