summaryrefslogtreecommitdiff
path: root/config.mak.dev
AgeCommit message (Collapse)AuthorFilesLines
2021-09-28Makefile: restrict -Wpedantic and -Wno-pedantic-ms-format betterLibravatar Carlo Marcelo Arenas Belón1-1/+6
6a8cbc41ba (developer: enable pedantic by default, 2021-09-03) enables pedantic mode in as many compilers as possible to help gather feedback on future tightening, so lets do so. -Wpedantic is missing in some really old gcc 4 versions so lets restrict it to gcc5 and clang4 (it does work in clang3 AFAIK, but it will be unlikely that a developer will use such an old compiler anyway). MinGW gcc is the only one which has -Wno-pedantic-ms-format, and while that is available also in older compilers, the Windows SDK provides gcc10 so lets aim for that. Note that in order to target the flag to only Windows, additional changes were needed in config.mak.uname to propagate the OS detection which also did some minor refactoring, but which is functionaly equivalent. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-27lazyload.h: use an even more generic function pointer than FARPROCLibravatar Carlo Marcelo Arenas Belón1-1/+0
gcc will helpfully raise a -Wcast-function-type warning when casting between functions that might have incompatible return types (ex: GetUserNameExW returns bool which is only half the size of the return type from FARPROC which is long long), so create a new type that could be used as a completely generic function pointer and cast through it instead. Additionaly remove the -Wno-incompatible-pointer-types temporary flag added in 27e0c3c (win32: allow building with pedantic mode enabled, 2021-09-03), as it will be no longer needed. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-03developer: enable pedantic by defaultLibravatar Carlo Marcelo Arenas Belón1-1/+3
With the codebase firmly C99 compatible and most compilers supporting newer versions by default, it could help bring visibility to problems. Reverse the DEVOPTS=pedantic flag to provide a fallback for people stuck with gcc < 5 or some other compiler that either doesn't support this flag or has issues with it, and while at it also enable -Wpedantic which used to be controversial[1] when Apple compilers and clang had widely divergent version numbers. Ideally any compiler found to have issues with these flags will be added to an exception, and indeed, one was added to safely process windows headers that would use non standard print identifiers, but it is expected that more will be needed, so it could be considered a weather balloon. [1] https://lore.kernel.org/git/20181127100557.53891-1-carenas@gmail.com/ Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-03win32: allow building with pedantic mode enabledLibravatar Carlo Marcelo Arenas Belón1-5/+8
In preparation to building with pedantic mode enabled, change a couple of places where the current mingw gcc compiler provided with the SDK reports issues. A full fix for the incompatible use of (void *) to store function pointers has been punted, with the minimal change to instead use a generic function pointer (FARPROC), and therefore the (hopefully) temporary need to disable incompatible pointer warnings. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-03gettext: remove optional non-standard parens in N_() definitionLibravatar Ævar Arnfjörð Bjarmason1-2/+0
Remove the USE_PARENS_AROUND_GETTEXT_N compile-time option which was meant to catch an inadvertent mistake which is too obscure to maintain this facility. The backstory of how USE_PARENS_AROUND_GETTEXT_N came about is: When I added the N_() macro in 65784830366 (i18n: add no-op _() and N_() wrappers, 2011-02-22) it was defined as: #define N_(msgid) (msgid) This is non-standard C, as was noticed and fixed in 642f85faab2 (i18n: avoid parenthesized string as array initializer, 2011-04-07). I.e. this needed to be defined as: #define N_(msgid) msgid Then in e62cd35a3e8 (i18n: log: mark parseopt strings for translation, 2012-08-20) when "builtin_log_usage" was marked for translation the string concatenation for passing to usage() added in 1c370ea4e51 (Show usage string for 'git log -h', 'git show -h' and 'git diff -h', 2009-08-06) was faithfully preserved: - "git log [<options>] [<since>..<until>] [[--] <path>...]\n" - " or: git show [options] <object>...", + N_("git log [<options>] [<since>..<until>] [[--] <path>...]\n") + N_(" or: git show [options] <object>..."), This was then fixed to be the expected array of usage strings in e66dc0cc4b1 (log.c: fix translation markings, 2015-01-06) rather than a string with multiple "\n"-delimited usage strings, and finally in 290c8e7a3fe (gettext.h: add parentheses around N_ expansion if supported, 2015-01-11) USE_PARENS_AROUND_GETTEXT_N was added to ensure this mistake didn't happen again. I think that even if this was a N_()-specific issue this USE_PARENS_AROUND_GETTEXT_N facility wouldn't be worth it, the issue would be too rare to worry about. But I also think that 290c8e7a3fe which introduced USE_PARENS_AROUND_GETTEXT_N misattributed the problem. The issue wasn't with the N_() macro added in e62cd35a3e8, but that before the N_() macro existed in the codebase the initial migration to parse_options() in 1c370ea4e51 continued passsing in a "\n"-delimited string, when the new API it was migrating to supported and expected the passing of an array. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-18Merge branch 'jc/sparse-error-for-developer-build'Libravatar Junio C Hamano1-0/+1
"make DEVELOPER=1 sparse" used to run sparse and let it emit warnings; now such warnings will cause an error. * jc/sparse-error-for-developer-build: Makefile: enable -Wsparse-error for DEVELOPER build
2020-11-09Merge branch 'jk/perl-warning'Libravatar Junio C Hamano1-0/+2
Dev support. * jk/perl-warning: perl: check for perl warnings while running tests
2020-11-02Merge branch 'jk/no-common'Libravatar Junio C Hamano1-0/+1
Dev support to catch a tentative definition of a variable in our C code as an error. * jk/no-common: config.mak.dev: build with -fno-common
2020-10-31Makefile: enable -Wsparse-error for DEVELOPER buildLibravatar Junio C Hamano1-0/+1
With -Wsparse-error, "make sparse" would fail, instead of just giving a warning message. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-21perl: check for perl warnings while running testsLibravatar Jeff King1-0/+2
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-16config.mak.dev: build with -fno-commonLibravatar Jeff King1-0/+1
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-07-30repository: enable SHA-256 support by defaultLibravatar brian m. carlson1-2/+0
Now that we have a complete SHA-256 implementation in Git, let's enable it so people can use it. Remove the ENABLE_SHA256 define constant everywhere it's used. Add tests for initializing a repository with SHA-256. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-26Merge branch 'bc/sha-256-part-1-of-4'Libravatar Junio C Hamano1-0/+2
SHA-256 transition continues. * bc/sha-256-part-1-of-4: (22 commits) fast-import: add options for rewriting submodules fast-import: add a generic function to iterate over marks fast-import: make find_marks work on any mark set fast-import: add helper function for inserting mark object entries fast-import: permit reading multiple marks files commit: use expected signature header for SHA-256 worktree: allow repository version 1 init-db: move writing repo version into a function builtin/init-db: add environment variable for new repo hash builtin/init-db: allow specifying hash algorithm on command line setup: allow check_repository_format to read repository format t/helper: make repository tests hash independent t/helper: initialize repository if necessary t/helper/test-dump-split-index: initialize git repository t6300: make hash algorithm independent t6300: abstract away SHA-1-specific constants t: use hash-specific lookup tables to define test constants repository: require a build flag to use SHA-256 hex: add functions to parse hex object IDs in any algorithm hex: introduce parsing variants taking hash algorithms ...
2020-02-28config.mak.dev: re-enable -Wformat-zero-lengthLibravatar Jeff King1-1/+0
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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-24repository: require a build flag to use SHA-256Libravatar brian m. carlson1-0/+2
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: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-24Makefile: allow for combining DEVELOPER=1 and CFLAGS="..."Libravatar Ævar Arnfjörð Bjarmason1-22/+22
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.html Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-18Merge branch 'jk/dev-build-format-security'Libravatar Junio C Hamano1-0/+1
Earlier we added "-Wformat-security" to developer builds, assuming that "-Wall" (which includes "-Wformat" which in turn is required to use "-Wformat-security") is always in effect. This is not true when config.mak.autogen is in use, unfortunately. This has been fixed by unconditionally adding "-Wall" to developer builds. * jk/dev-build-format-security: config.mak.dev: add -Wall, primarily for -Wformat, to help autoconf users
2019-01-07config.mak.dev: add -Wall, primarily for -Wformat, to help autoconf usersLibravatar Thomas Gummerer1-0/+1
801fa63a90 ("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: Thomas Gummerer <t.gummerer@gmail.com> Helped-by: Jeff King <peff@peff.net> Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-30Merge branch 'jk/unused-function'Libravatar Junio C Hamano1-1/+0
Developer support. * jk/unused-function: config.mak.dev: enable -Wunused-function
2018-10-19config.mak.dev: enable -Wunused-functionLibravatar Jeff King1-1/+0
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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-24Merge branch 'jk/dev-build-format-security'Libravatar Junio C Hamano1-0/+1
Build tweak to help developers. * jk/dev-build-format-security: config.mak.dev: add -Wformat-security
2018-09-11config.mak.dev: add -Wformat-securityLibravatar Jeff King1-0/+1
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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-25Makefile: add a DEVOPTS flag to get pedantic compilationLibravatar Beat Bolli1-0/+5
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: Beat Bolli <dev+git@drbeat.li> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-16Makefile: add a DEVOPTS to get all of -WextraLibravatar Ævar Arnfjörð Bjarmason1-0/+2
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: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-16Makefile: add a DEVOPTS to suppress -Werror under DEVELOPERLibravatar Ævar Arnfjörð Bjarmason1-0/+2
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: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-16Makefile: detect compiler and enable more warnings in DEVELOPER=1Libravatar Nguyễn Thái Ngọc Duy1-0/+38
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: Jeff King <peff@peff.net> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>