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

config.mak.dev: disable suggest braces error on old clang versions

2022-10-10T18:15:31Z

Add the "-Wno-missing-braces" option when building with an old version of clang to suppress the "suggest braces around initialization" error in developer mode. For example, using an old version of clang gives the following errors (when in DEVELOPER=1 mode): $ make builtin/merge-file.o CC builtin/merge-file.o builtin/merge-file.c:29:23: error: suggest braces around initialization \ of subobject [-Werror,-Wmissing-braces] mmfile_t mmfs[3] = { 0 }; ^ {} builtin/merge-file.c:31:20: error: suggest braces around initialization \ of subobject [-Werror,-Wmissing-braces] xmparam_t xmp = { 0 }; ^ {} 2 errors generated. This example compiles without error/warning with updated versions of clang. Since this is an obsolete error, use the -Wno-missing-braces option to silence the warning when using an older compiler. This avoids the need to update the code to use "{{0}}" style initializations. Upstream clang version 8 has the problem. It was fixed in version 9. The version of clang distributed by Apple with XCode has its own unique set of version numbers. Apple clang version 11 has the problem. It was fixed in version 12. Signed-off-by: Jeff Hostetler Signed-off-by: Junio C Hamano

config.mak.dev: squelch -Wno-missing-braces for older gcc

2022-07-31T18:50:07Z

Versions of gcc prior to 4.9 complain about an initialization like: struct inner { int x; }; struct outer { struct inner; }; struct outer foo = { 0 }; and insist on: struct outer foo = { { 0 } }; Newer compilers handle this just fine. And ignoring the window even on older compilers is fine; the resulting code is correct, but we just get caught by -Werror. Let's relax this for older compilers to make developer lives easier (we don't care much about non-developers on old compilers; they may see a warning, but it won't stop compilation). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

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