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

Revert -Wno-error=dangling-pointer

2022-06-01T15:49:13Z

This reverts commit 9c539d1027 (config.mak.dev: alternative workaround to gcc 12 warning in http.c, 2022-04-15). Let's give GCC12's "dangling-pointer" warning a second chance, as we have a more focused workaround for this particular compiler glitch. Signed-off-by: Junio C Hamano

config.mak.dev: alternative workaround to gcc 12 warning in http.c

2022-04-15T23:27:04Z

This provides a "no code change needed" option to the "fix" currently queued as part of ab/http-gcc-12-workaround and therefore should be reverted once that gets merged. Signed-off-by: Carlo Marcelo Arenas Belón Signed-off-by: Junio C Hamano

config.mak.dev: workaround gcc 12 bug affecting "pedantic" CI job

2022-04-15T23:26:16Z

Originally noticed by Peff[1], but yet to be corrected[2] and planned to be released with Fedora 36 (scheduled for Apr 19). dir.c: In function ‘git_url_basename’: dir.c:3085:13: error: ‘memchr’ specified bound [9223372036854775808, 0] exceeds maximum object size 9223372036854775807 [-Werror=stringop-overread] 3085 | if (memchr(start, '/', end - start) == NULL | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fedora is used as part of the CI, and therefore that release will trigger failures, unless the version of the image used is locked to an older release, as an alternative. Restricting the flag to the affected source file, as well as implementing an independent facility to track these workarounds was specifically punted to minimize the risk of introducing problems so close to a release. This change should be reverted once the underlying gcc bug is solved and which should be visible by NOT triggering a warning, otherwise. [1] https://lore.kernel.org/git/YZQhLh2BU5Hquhpo@coredump.intra.peff.net/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=2075786 Signed-off-by: Carlo Marcelo Arenas Belón Signed-off-by: Junio C Hamano

Makefile: FreeBSD cannot do C99-or-below build

2022-01-18T20:16:23Z

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

config.mak.dev: specify -std=gnu99 for gcc/clang

2021-12-08T21:16:44Z

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

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