git/config.mak.dev, branch v2.34.2

Makefile: restrict -Wpedantic and -Wno-pedantic-ms-format better

2021-09-29T04:15:53Z

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 Signed-off-by: Carlo Marcelo Arenas Belón Signed-off-by: Junio C Hamano

lazyload.h: use an even more generic function pointer than FARPROC

2021-09-27T20:13:58Z

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 Signed-off-by: Junio C Hamano

developer: enable pedantic by default

2021-09-03T18:40:30Z

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 Signed-off-by: Junio C Hamano

win32: allow building with pedantic mode enabled

2021-09-03T18:40:30Z

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 Signed-off-by: Junio C Hamano

gettext: remove optional non-standard parens in N_() definition

2021-09-03T18:40:30Z

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 [] [..] [[--] ...]\n" - " or: git show [options] ...", + N_("git log [] [..] [[--] ...]\n") + N_(" or: git show [options] ..."), 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 Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Carlo Marcelo Arenas Belón Signed-off-by: Junio C Hamano

Merge branch 'jc/sparse-error-for-developer-build'

2020-11-18T21:32:54Z

"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

Merge branch 'jk/perl-warning'

2020-11-09T22:06:25Z

Dev support. * jk/perl-warning: perl: check for perl warnings while running tests

Merge branch 'jk/no-common'

2020-11-02T21:17:41Z

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

Makefile: enable -Wsparse-error for DEVELOPER build

2020-10-31T22:24:40Z

With -Wsparse-error, "make sparse" would fail, instead of just giving a warning message. Signed-off-by: Junio C Hamano

perl: check for perl warnings while running tests

2020-10-22T06:11:48Z

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 Signed-off-by: Junio C Hamano