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

config.mak.dev: drop `-Wno-sign-compare`

2024-12-06T11:20:02Z

There is no need anymore to disable `-Wsign-compare` now that all files that cause warnings have been marked accordingly. Drop the option. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'ak/typofix-2.46-maint'

2024-09-25T17:37:12Z

Typofix. * ak/typofix-2.46-maint: upload-pack: fix a typo sideband: fix a typo setup: fix a typo run-command: fix a typo revision: fix a typo refs: fix typos rebase: fix a typo read-cache-ll: fix a typo pretty: fix a typo object-file: fix a typo merge-ort: fix typos merge-ll: fix a typo http: fix a typo gpg-interface: fix a typo git-p4: fix typos git-instaweb: fix a typo fsmonitor-settings: fix a typo diffcore-rename: fix typos config.mak.dev: fix a typo

config.mak.dev: fix a typo

2024-09-19T20:45:59Z

Fix a typo in comments. Signed-off-by: Andrew Kreimer Signed-off-by: Junio C Hamano

config.mak.dev: enable -Wunused-parameter by default

2024-08-28T16:51:18Z

Having now removed or annotated all of the unused function parameters in our code base, I found that each instance falls into one of three categories: 1. ignoring the parameter is a bug (e.g., a function takes a ptr/len pair, but ignores the length). Detecting these helps us find the bugs. 2. the parameter is unnecessary (and usually left over from a refactoring or earlier iteration of a patches series). Removing these cleans up the code. 3. the function has to conform to a specific interface (because it's used via a function pointer, or matches something on the other side of an #ifdef). These ones are annoying, but annotating them with UNUSED is not too bad (especially if the compiler tells you about the problem promptly). Certainly instances of (3) are more common than (1), but after finding all of these, I think there were enough cases of (1) that it justifies the work in annotating all of the (3)s. And since the code base is now at a spot where we compile cleanly with -Wunused-parameter, turning it on will make it the responsibility of individual patch writers going forward. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'tb/dev-build-pedantic-fix'

2024-07-15T17:11:42Z

Developer build procedure fix. * tb/dev-build-pedantic-fix: config.mak.dev: fix typo when enabling -Wpedantic

config.mak.dev: fix typo when enabling -Wpedantic

2024-07-06T22:10:29Z

In ebd2e4a13a (Makefile: restrict -Wpedantic and -Wno-pedantic-ms-format better, 2021-09-28), we tightened our Makefile's behavior to only enable -Wpedantic when compiling with either gcc5/clang4 or greater as older compiler versions did not have support for -Wpedantic. Commit ebd2e4a13a was looking for either "gcc5" or "clang4" to appear in the COMPILER_FEATURES variable, combining the two "$(filter ...)" searches with an "$(or ...)". But ebd2e4a13a has a typo where instead of writing: ifneq ($(or ($filter ...),$(filter ...)),) we wrote: ifneq (($or ($filter ...),$(filter ...)),) Causing our Makefile (when invoked with DEVELOPER=1, and a sufficiently recent compiler version) to barf: $ make DEVELOPER=1 config.mak.dev:13: extraneous text after 'ifneq' directive [...] Correctly combine the results of the two "$(filter ...)" operations by using "$(or ...)", not "$or". Signed-off-by: Taylor Blau Signed-off-by: Junio C Hamano

config.mak.dev: enable `-Wwrite-strings` warning

2024-06-07T17:30:56Z

Writing to string constants is undefined behaviour and must be avoided in C. Even so, the compiler does not help us with this by default because those constants are not in fact marked as `const`. This makes it rather easy to accidentally assign a constant to a non-const variable or field and then later on try to either free it or write to it. Enable `-Wwrite-strings` to catch such mistakes. With this warning enabled, the type of string constants is changed to `const char[]` and will thus cause compiler warnings when being assigned to non-const fields and variables. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

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