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: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We recently triggered some -Wformat-zero-length warnings in the code,
but no developers noticed because we suppress that warning in builds
with the DEVELOPER=1 Makefile knob set. But we _don't_ suppress them in
a non-developer build (and they're part of -Wall). So even though
non-developers probably aren't using -Werror, they see the annoying
warnings when they build.

We've had back and forth discussion over the years on whether this
warning is useful or not. In most cases we've seen, it's not true that
the call is a mistake, since we're using its side effects (like adding a
newline status_printf_ln()) or writing an empty string to a destination
which is handled by the function (as in write_file()). And so we end up
working around it in the source by passing ("%s", "").

There's more discussion in the subthread starting at:

  https://lore.kernel.org/git/xmqqtwaod7ly.fsf@gitster.mtv.corp.google.com/

The short of it is that we probably can't just disable the warning for
everybody because of portability issues. And ignoring it for developers
puts us in the situation we're in now, where non-dev builds are annoyed.

Since the workaround is both rarely needed and fairly straight-forward,
let's just commit to doing it as necessary, and re-enable the warning.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

At this point, SHA-256 support is experimental and some behavior may
change. To avoid surprising unsuspecting users, require a build flag,
ENABLE_SHA256, to allow use of a non-SHA-1 algorithm. Enable this flag
by default when the DEVELOPER make flag is set so that contributors can
test this case adequately.
Signed-off-by: Nbrian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Ever since the DEVELOPER=1 facility introduced there's been no way to
have custom CFLAGS (e.g. CFLAGS="-O0 -g -ggdb3") while still
benefiting from the set of warnings and assertions DEVELOPER=1
enables.

This is because the semantics of variables in the Makefile are such
that the user setting CFLAGS overrides anything we set, including what
we're doing in config.mak.dev[1].

So let's introduce a "DEVELOPER_CFLAGS" variable in config.mak.dev and
add it to ALL_CFLAGS. Before this the ALL_CFLAGS variable
would (basically, there's some nuance we won't go into) be set to:

    $(CPPFLAGS) [$(CFLAGS) *or* $(CFLAGS) in config.mak.dev] $(BASIC_CFLAGS) $(EXTRA_CPPFLAGS)

But will now be:

    $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS) $(BASIC_CFLAGS) $(EXTRA_CPPFLAGS)

The reason for putting DEVELOPER_CFLAGS first is to allow for
selectively overriding something DEVELOPER=1 brings in. On both GCC
and Clang later settings override earlier ones. E.g. "-Wextra
-Wno-extra" will enable no "extra" warnings, but not if those two
arguments are reversed.

Examples of things that weren't possible before, but are now:

    # Use -O0 instead of -O2 for less painful debuggng
    DEVELOPER=1 CFLAGS="-O0 -g"
    # DEVELOPER=1 plus -Wextra, but disable some of the warnings
    DEVELOPER=1 DEVOPTS="no-error extra-all" CFLAGS="-O0 -g -Wno-unused-parameter"

The reason for the patches leading up to this one re-arranged the
various *FLAGS assignments and includes is just for readability. The
Makefile supports assignments out of order, e.g.:

    $ cat Makefile
    X = $(A) $(B) $(C)
    A = A
    B = B
    include c.mak
    all:
            @echo $(X)
    $ cat c.mak
    C=C
    $ make
    A B C

So we could have gotten away with the much smaller change of changing
"CFLAGS" in config.mak.dev to "DEVELOPER_CFLAGS" and adding that to
ALL_CFLAGS earlier in the Makefile "before" the config.mak.*
includes. But I think it's more readable to use variables "after"
they're included.

1. https://www.gnu.org/software/make/manual/html_node/Overriding.htmlSigned-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

801fa63a ("config.mak.dev: add -Wformat-security", 2018-09-08)
added the "-Wformat-security" to the flags set in config.mak.dev.
In the gcc man page this is documented as:

         If -Wformat is specified, also warn about uses of format
         functions that represent possible security problems.  [...]

The commit did however not add the "-Wformat" flag, but instead
relied on the fact that "-Wall" is set in the Makefile by default
and that "-Wformat" is part of "-Wall".

Unfortunately, those who use config.mak.autogen generated with the
autoconf to configure toolchain do *not* get "-Wall" in their CFLAGS
and the added -Wformat-security had no effect.  Worse yet, newer
versions of gcc (gcc 8.2.1 in this particular case) warn about the
lack of "-Wformat" and thus compilation fails only with this option
set.

We could fix it by adding "-Wformat", but in general we do want all
checks included in "-Wall", so let's add it to config.mak.dev to
cover more cases.
Signed-off-by: NThomas Gummerer <t.gummerer@gmail.com>
Helped-by: NJeff King <peff@peff.net>
Helped-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We explicitly omitted -Wunused-function when we added
-Wextra, but there is no need: the current code compiles
cleanly with it. And it's worth having, since it can let you
know when there are cascading effects from a cleanup (e.g.,
deleting one function lets you delete its static helpers).

There are cases where we may need an unused function to
exist, but we can handle these easily:

  - macro-generated code like commit-slab; there we have the
    MAYBE_UNUSED annotation to silence the compiler

  - conditional compilation, where we may or may not need a
    static helper. These generally fall into one of two
    categories:

      - the call should not be conditional, but rather the
	function body itself should be (and may just be a
	no-op on one side of the #if). That keeps the
	conditional pollution out of the main code.

      - call-chains of static helpers should all be in the
        same #if block, so they are all-or-nothing

    And if there's some case that doesn't cover, we still
    have MAYBE_UNUSED as a fallback.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We currently build cleanly with -Wformat-security, and it's
a good idea to make sure we continue to do so (since calls
that trigger the warning may be security vulnerabilities).

Note that we cannot use the stronger -Wformat-nonliteral, as
there are case where we are clever with passing around
pointers to string literals. E.g., bisect_rev_setup() takes
bad_format and good_format parameters. These ultimately come
from literals, but they still trigger the warning.

Some of these might be fixable (e.g., by passing flags from
which we locally select a format), and might even be worth
fixing (not because of security, but just because it's an
easy mistake to pass the wrong format). But there are other
cases which are likely quite hard to fix (we actually
generate formats in a local buffer in some cases). So let's
punt on that for now and start with -Wformat-security, which
is supposed to catch the most important cases.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In the interest of code hygiene, make it easier to compile Git with the
flag -pedantic.

Pure pedantic compilation with GCC 7.3 results in one warning per use of
the translation macro `N_`:

    warning: array initialized from parenthesized string constant [-Wpedantic]

Therefore also disable the parenthesising of i18n strings with
-DUSE_PARENS_AROUND_GETTEXT_N=0.
Signed-off-by: NBeat Bolli <dev+git@drbeat.li>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Change DEVOPTS to understand a "extra-all" option. When the DEVELOPER
flag is enabled we turn on -Wextra, but manually switch some of the
warnings it turns on off.

This is because we have many existing occurrences of them in the code
base. This mode will stop the suppression, let the developer see and
decide whether to  fix them.

This change is a slight alteration of Nguyễn Thái Ngọc Duy
EAGER_DEVELOPER mode patch[1]

1. "[PATCH v3 3/3] Makefile: add EAGER_DEVELOPER
    mode" (<20180329150322.10722-4-pclouds@gmail.com>;
    https://public-inbox.org/git/20180329150322.10722-4-pclouds@gmail.com/)
Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Add a DEVOPTS variable that'll be used to tweak the behavior of
DEVELOPER.

I've long wanted to use DEVELOPER=1 in my production builds, but on
some old systems I still get warnings, and thus the build would
fail. However if the build/tests fail for some other reason, it would
still be useful to scroll up and see what the relevant code is warning
about.

This change allows for that. Now setting DEVELOPER will set -Werror as
before, but if DEVOPTS=no-error is provided is set you'll get the same
warnings, but without -Werror.
Helped-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The set of extra warnings we enable when DEVELOPER has to be
conservative because we can't assume any compiler version the
developer may use. Detect the compiler version so we know when it's
safe to enable -Wextra and maybe more.

These warning settings are mostly from my custom config.mak a long
time ago when I tried to enable as many warnings as possible that can
still build without showing warnings. Some of those warnings are
probably worth fixing instead of just suppressing in future.
Helped-by: NJeff King <peff@peff.net>
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>