{"thread":{"id":"58576","subject":"[PATCH 0/2] Fix syntax errors under clang 11.0.0 on MacOS","startedAt":"2022-10-06T19:43:25Z","lastAt":"2022-10-11T00:15:26Z","messageCount":21,"participants":["Jeff Hostetler via GitGitGadget","Junio C Hamano","Eric Sunshine","René Scharfe","Ævar Arnfjörð Bjarmason","Jeff Hostetler"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"464322","messageId":"pull.1375.git.1665085395.gitgitgadget@gmail.com","threadId":"58576","inReplyTo":null,"subject":"[PATCH 0/2] Fix syntax errors under clang 11.0.0 on MacOS","fromName":"Jeff Hostetler via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-10-06T19:43:13Z","receivedAt":"2022-10-06T19:43:25Z","isPatch":true,"sender":{"key":"git@jeffhostetler.com","avatar":null},"body":"This patch series fixes three syntax errors that caused compiler errors with\nclang 11.0.0 on MacOS. I've included the error/warning messages in the\ncommit messages. The offending statements did compile successfully under\nclang 14.0.0 on MacOS, so I have to assume that this usage is newer than\nwhat clang 11 supports.\n\nI originally sent these changes in my \"Trace2 timers and cleanup and some\ncleanup\" series on Tuesday, but pulled them into a separate series based on\nfeedback. I'll omit them from the trace2 series in the next version.\n\nJeff Hostetler (2):\n builtin/merge-file: fix compiler error on MacOS with clang 11.0.0\n builtin/unpack-objects.c: fix compiler error on MacOS with clang\n 11.0.0\n\n builtin/merge-file.c | 4 ++--\n builtin/unpack-objects.c | 2 +-\n 2 files changed, 3 insertions(+), 3 deletions(-)\n\n\nbase-commit: 3dcec76d9df911ed8321007b1d197c1a206dc164\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-1375%2Fjeffhostetler%2Ffix-clang11-warnings-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1375/jeffhostetler/fix-clang11-warnings-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/1375\n-- \ngitgitgadget\n"},{"id":"464323","messageId":"7cee38788a7a3c2c09a238e01c5bd825445f999d.1665085395.git.gitgitgadget@gmail.com","threadId":"58576","inReplyTo":"pull.1375.git.1665085395.gitgitgadget@gmail.com","subject":"[PATCH 1/2] builtin/merge-file: fix compiler error on MacOS with clang 11.0.0","fromName":"Jeff Hostetler via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-10-06T19:43:14Z","receivedAt":"2022-10-06T19:43:29Z","isPatch":true,"sender":{"key":"git@jeffhostetler.com","avatar":null},"body":"From: Jeff Hostetler \n\nAdd extra set of braces around zero initialization of two array/structure\nvariables to resolve compiler errors/warnings from clang 11.0.0 on MacOS.\nThis is not needed on clang 14.0.\n\n$ uname -a\nDarwin jeffhost-mbp.local 19.6.0 Darwin Kernel Version 19.6.0: \\\n Mon Apr 18 21:50:40 PDT 2022; \\\n root:xnu-6153.141.62~1/RELEASE_X86_64 x86_64\n$ clang -v\nApple clang version 11.0.0 (clang-1100.0.33.17)\nTarget: x86_64-apple-darwin19.6.0\n[...]\n\n$ make builtin/merge-file.o\n CC builtin/merge-file.o\nbuiltin/merge-file.c:29:23: error: suggest braces around initialization \\\n\t\t\t of subobject [-Werror,-Wmissing-braces]\n mmfile_t mmfs[3] = { 0 };\n ^\n {}\nbuiltin/merge-file.c:31:20: error: suggest braces around initialization \\\n\t\t\t of subobject [-Werror,-Wmissing-braces]\n xmparam_t xmp = { 0 };\n ^\n {}\n2 errors generated.\nmake: *** [builtin/merge-file.o] Error 1\n\nSigned-off-by: Jeff Hostetler \n---\n builtin/merge-file.c | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin/merge-file.c b/builtin/merge-file.c\nindex c923bbf2abb..607c3d3f9e1 100644\n--- a/builtin/merge-file.c\n+++ b/builtin/merge-file.c\n@@ -26,9 +26,9 @@ static int label_cb(const struct option *opt, const char *arg, int unset)\n int cmd_merge_file(int argc, const char **argv, const char *prefix)\n {\n \tconst char *names[3] = { 0 };\n-\tmmfile_t mmfs[3] = { 0 };\n+\tmmfile_t mmfs[3] = { { 0 } };\n \tmmbuffer_t result = { 0 };\n-\txmparam_t xmp = { 0 };\n+\txmparam_t xmp = { { 0 } };\n \tint ret = 0, i = 0, to_stdout = 0;\n \tint quiet = 0;\n \tstruct option options[] = {\n-- \ngitgitgadget\n\n"},{"id":"464324","messageId":"e5009a325f234eef7e80335e458fbe11a2ccf5f4.1665085395.git.gitgitgadget@gmail.com","threadId":"58576","inReplyTo":"pull.1375.git.1665085395.gitgitgadget@gmail.com","subject":"[PATCH 2/2] builtin/unpack-objects.c: fix compiler error on MacOS with clang 11.0.0","fromName":"Jeff Hostetler via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-10-06T19:43:15Z","receivedAt":"2022-10-06T19:43:30Z","isPatch":true,"sender":{"key":"git@jeffhostetler.com","avatar":null},"body":"From: Jeff Hostetler \n\nAdd an extra set of braces around zero initialization of the `zstream`\nvariable to resolve compiler error/warning from clang 11.0.0 on MacOS.\nThis is not needed on clang 14.0.\n\n$ make builtin/unpack-objects.o\n CC builtin/unpack-objects.o\nbuiltin/unpack-objects.c:388:26: error: suggest braces around \\\n\t\tinitialization of subobject [-Werror,-Wmissing-braces]\n git_zstream zstream = { 0 };\n ^\n {}\n1 error generated.\nmake: *** [builtin/unpack-objects.o] Error 1\n\nSigned-off-by: Jeff Hostetler \n---\n builtin/unpack-objects.c | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/builtin/unpack-objects.c b/builtin/unpack-objects.c\nindex 43789b8ef29..4b16f1592ba 100644\n--- a/builtin/unpack-objects.c\n+++ b/builtin/unpack-objects.c\n@@ -385,7 +385,7 @@ static const void *feed_input_zstream(struct input_stream *in_stream,\n \n static void stream_blob(unsigned long size, unsigned nr)\n {\n-\tgit_zstream zstream = { 0 };\n+\tgit_zstream zstream = { { 0 } };\n \tstruct input_zstream_data data = { 0 };\n \tstruct input_stream in_stream = {\n \t\t.read = feed_input_zstream,\n-- \ngitgitgadget\n"},{"id":"464327","messageId":"xmqqh70gk7qk.fsf@gitster.g","threadId":"58576","inReplyTo":"pull.1375.git.1665085395.gitgitgadget@gmail.com","subject":"Re: [PATCH 0/2] Fix syntax errors under clang 11.0.0 on MacOS","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-10-06T20:38:43Z","receivedAt":"2022-10-06T20:39:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Jeff Hostetler via GitGitGadget\" writes:\n\n> This patch series fixes three syntax errors that caused compiler errors with\n> clang 11.0.0 on MacOS. I've included the error/warning messages in the\n> commit messages. The offending statements did compile successfully under\n> clang 14.0.0 on MacOS, so I have to assume that this usage is newer than\n> what clang 11 supports.\n\nAh, this looked familiar, and the last time we saw the one in\nbuiltin/unpack-objects.c\n\nhttps://lore.kernel.org/git/20220710081135.74964-1-sunshine@sunshineco.com/\n\nIt seems that merge-file.c was OK back then but soon after we\n\"broke\" it with 480a0e30 (merge-file: refactor for subsequent memory\nleak fix, 2022-07-01).\n\n $ git grep -n -e '{ *{ *0 *} *}'\n builtin/merge-index.c:15:\tchar oids[3][GIT_MAX_HEXSZ + 1] = {{0}};\n builtin/merge-index.c:16:\tchar modes[3][10] = {{0}};\n builtin/worktree.c:321:\t\tstruct config_set cs = { { 0 } };\n merge-strategies.c:93:\txmparam_t xmp = {{0}};\n oidset.h:25:#define OIDSET_INIT { { 0 } }\n worktree.c:795:\tstruct config_set cs = { { 0 } };\n\nI wonder if we want to introduce some named _INIT for these specific\ntypes? Perhaps with something like\n\n /* for config_set */\n #define CONFIG_SET_INIT {{0}}\n /* for xmparam_t */\n #define XMPARAM_INIT {{0}}\n /* for mmfile_t */\n #define MMFILE_INIT {0}\n /* for git_zstream */\n #define GIT_ZSTREAM_INIT {{0}}\n\n\tSide note: between { { 0 } } and {{0}} forms that appear in\n\tthe existing code, I picked the \"unusual spacing\" variant,\n\ti.e. without any space, hoping that it would signal the fact\n\tthat we would prefer if we didn't have to use these to\n\tplease older compilers to the readers.\n\nUnless we plan to soon declare that clang 11 is too old to matter\nanymore, that is.\n\nThe rule, tentatively until the compilers that need extra levels of\nbraces die out, can be \"if there is _INIT for the type, you\nshould use it, but otherwise you can do { 0 }\", or something like\nthat, perhaps?\n\n"},{"id":"464330","messageId":"CAPig+cRKwe-yEpYv=WAnwFBsBtTAkHuujvajokNZ0qm989LRdA@mail.gmail.com","threadId":"58576","inReplyTo":"xmqqh70gk7qk.fsf@gitster.g","subject":"Re: [PATCH 0/2] Fix syntax errors under clang 11.0.0 on MacOS","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2022-10-06T20:58:53Z","receivedAt":"2022-10-06T20:59:09Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Thu, Oct 6, 2022 at 4:41 PM Junio C Hamano wrote:\n> \"Jeff Hostetler via GitGitGadget\" writes:\n> > This patch series fixes three syntax errors that caused compiler errors with\n> > clang 11.0.0 on MacOS. I've included the error/warning messages in the\n> > commit messages. The offending statements did compile successfully under\n> > clang 14.0.0 on MacOS, so I have to assume that this usage is newer than\n> > what clang 11 supports.\n>\n> Ah, this looked familiar, and the last time we saw the one in\n> builtin/unpack-objects.c\n>\n> https://lore.kernel.org/git/20220710081135.74964-1-sunshine@sunshineco.com/\n>\n> It seems that merge-file.c was OK back then but soon after we\n> \"broke\" it with 480a0e30 (merge-file: refactor for subsequent memory\n> leak fix, 2022-07-01).\n\nFor completeness, the merge-file.c instance also got reported:\nhttps://lore.kernel.org/git/365e01e93dce582e9d926e83bdc6891310d22699.1659084832.git.congdanhqx@gmail.com/\n"},{"id":"464331","messageId":"36cd156b-edb2-062c-9422-bf39aad39a6d@web.de","threadId":"58576","inReplyTo":"7cee38788a7a3c2c09a238e01c5bd825445f999d.1665085395.git.gitgitgadget@gmail.com","subject":"Re: [PATCH 1/2] builtin/merge-file: fix compiler error on MacOS with clang 11.0.0","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2022-10-06T21:09:13Z","receivedAt":"2022-10-06T21:09:23Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 06.10.22 um 21:43 schrieb Jeff Hostetler via GitGitGadget:\n> From: Jeff Hostetler \n>\n> Add extra set of braces around zero initialization of two array/structure\n> variables to resolve compiler errors/warnings from clang 11.0.0 on MacOS.\n> This is not needed on clang 14.0.\n\nNot sure how the Apple version numbers map to LLVM versions. I can\nreproduce it with Godbolt's Compiler Explorer with clang 8, but not\nwith clang 9 or higher: https://godbolt.org/z/f7f7s9xxz\n\nFunny that type of the \"inner\" member seems to affect the warning.\n\n>\n> $ uname -a\n> Darwin jeffhost-mbp.local 19.6.0 Darwin Kernel Version 19.6.0: \\\n> Mon Apr 18 21:50:40 PDT 2022; \\\n> root:xnu-6153.141.62~1/RELEASE_X86_64 x86_64\n> $ clang -v\n> Apple clang version 11.0.0 (clang-1100.0.33.17)\n> Target: x86_64-apple-darwin19.6.0\n> [...]\n>\n> $ make builtin/merge-file.o\n> CC builtin/merge-file.o\n> builtin/merge-file.c:29:23: error: suggest braces around initialization \\\n> \t\t\t of subobject [-Werror,-Wmissing-braces]\n> mmfile_t mmfs[3] = { 0 };\n> ^\n> {}\n\n{0} is an idiom to zero-initialize any struct, no matter how deeply\nnested. It's valid C and the compiler warning about it is not helpful.\nShouldn't we rather silence it with -Wno-missing-braces?\n\nOn the other hand: Uglifying just three initializations in total isn't\nthat bad. The issue may reappear, though, because most people use\ncompilers that don't issue that spurious warning, I imagine.\n\n> builtin/merge-file.c:31:20: error: suggest braces around initialization \\\n> \t\t\t of subobject [-Werror,-Wmissing-braces]\n> xmparam_t xmp = { 0 };\n> ^\n> {}\n> 2 errors generated.\n> make: *** [builtin/merge-file.o] Error 1\n>\n> Signed-off-by: Jeff Hostetler \n> ---\n> builtin/merge-file.c | 4 ++--\n> 1 file changed, 2 insertions(+), 2 deletions(-)\n>\n> diff --git a/builtin/merge-file.c b/builtin/merge-file.c\n> index c923bbf2abb..607c3d3f9e1 100644\n> --- a/builtin/merge-file.c\n> +++ b/builtin/merge-file.c\n> @@ -26,9 +26,9 @@ static int label_cb(const struct option *opt, const char *arg, int unset)\n> int cmd_merge_file(int argc, const char **argv, const char *prefix)\n> {\n> \tconst char *names[3] = { 0 };\n> -\tmmfile_t mmfs[3] = { 0 };\n> +\tmmfile_t mmfs[3] = { { 0 } };\n> \tmmbuffer_t result = { 0 };\n> -\txmparam_t xmp = { 0 };\n> +\txmparam_t xmp = { { 0 } };\n> \tint ret = 0, i = 0, to_stdout = 0;\n> \tint quiet = 0;\n> \tstruct option options[] = {\n\n"},{"id":"464337","messageId":"CAPig+cT7_H6EDU9s1G38QrepACzN2vzCopAn7S=PDb0so_F21A@mail.gmail.com","threadId":"58576","inReplyTo":"36cd156b-edb2-062c-9422-bf39aad39a6d@web.de","subject":"Re: [PATCH 1/2] builtin/merge-file: fix compiler error on MacOS with clang 11.0.0","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2022-10-06T22:30:56Z","receivedAt":"2022-10-06T22:31:13Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Thu, Oct 6, 2022 at 5:25 PM René Scharfe wrote:\n> Am 06.10.22 um 21:43 schrieb Jeff Hostetler via GitGitGadget:\n> > Add extra set of braces around zero initialization of two array/structure\n> > variables to resolve compiler errors/warnings from clang 11.0.0 on MacOS.\n> > This is not needed on clang 14.0.\n>\n> Not sure how the Apple version numbers map to LLVM versions. I can\n> reproduce it with Godbolt's Compiler Explorer with clang 8, but not\n> with clang 9 or higher: https://godbolt.org/z/f7f7s9xxz\n>\n> > builtin/merge-file.c:29:23: error: suggest braces around initialization \\\n> > of subobject [-Werror,-Wmissing-braces]\n> > mmfile_t mmfs[3] = { 0 };\n> > ^\n> > {}\n>\n> {0} is an idiom to zero-initialize any struct, no matter how deeply\n> nested. It's valid C and the compiler warning about it is not helpful.\n> Shouldn't we rather silence it with -Wno-missing-braces?\n\nThat was indeed Ævar's suggestion in [1]:\n\n Since this is only a warning, and only a practical issue with\n -Werror I wonder if a config.mak.dev change wouldn't be better,\n i.e. to provide a -Wno-missing-braces for this older clang\n version.\n\nThe problem is that Apple seems to invent their version numbers out of\nthin air with no relation to reality[2,3], so it may take some effort\nto work out suitable \"version mapping rules\" for config.mak.dev, and\nnobody has done it yet.\n\n[1]: https://lore.kernel.org/git/220712.86lesy6cri.gmgdl@evledraar.gmail.com/\n[2]: https://lore.kernel.org/git/Ys0hhYjPExuNWynE@coredump.intra.peff.net/\n[3]: https://lore.kernel.org/git/YQ2LdvwEnZN9LUQn@coredump.intra.peff.net/\n"},{"id":"464338","messageId":"xmqqczb4in0r.fsf@gitster.g","threadId":"58576","inReplyTo":"CAPig+cT7_H6EDU9s1G38QrepACzN2vzCopAn7S=PDb0so_F21A@mail.gmail.com","subject":"Re: [PATCH 1/2] builtin/merge-file: fix compiler error on MacOS with clang 11.0.0","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-10-06T22:51:32Z","receivedAt":"2022-10-06T22:51:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine writes:\n\n>> Shouldn't we rather silence it with -Wno-missing-braces?\n>\n> That was indeed Ævar's suggestion in [1]:\n>\n> Since this is only a warning, and only a practical issue with\n> -Werror I wonder if a config.mak.dev change wouldn't be better,\n> i.e. to provide a -Wno-missing-braces for this older clang\n> version.\n>\n> The problem is that Apple seems to invent their version numbers out of\n> thin air with no relation to reality[2,3], so it may take some effort\n> to work out suitable \"version mapping rules\" for config.mak.dev, and\n> nobody has done it yet.\n>\n> [1]: https://lore.kernel.org/git/220712.86lesy6cri.gmgdl@evledraar.gmail.com/\n> [2]: https://lore.kernel.org/git/Ys0hhYjPExuNWynE@coredump.intra.peff.net/\n> [3]: https://lore.kernel.org/git/YQ2LdvwEnZN9LUQn@coredump.intra.peff.net/\n\nI agree that telling affected users to squelch the warning is a good\nfirst step, and automating it, if there is an easy implementation to\ndo so, would be a good thing to have on top.\n\nThanks for digging up the thread.\n\n\n"},{"id":"464368","messageId":"221007.861qrjriul.gmgdl@evledraar.gmail.com","threadId":"58576","inReplyTo":"pull.1375.git.1665085395.gitgitgadget@gmail.com","subject":"Re: [PATCH 0/2] Fix syntax errors under clang 11.0.0 on MacOS","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-10-07T11:02:39Z","receivedAt":"2022-10-07T11:09:14Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Oct 06 2022, Jeff Hostetler via GitGitGadget wrote:\n\n> This patch series fixes three syntax errors that caused compiler errors with\n> clang 11.0.0 on MacOS. I've included the error/warning messages in the\n> commit messages. The offending statements did compile successfully under\n> clang 14.0.0 on MacOS, so I have to assume that this usage is newer than\n> what clang 11 supports.\n>\n> I originally sent these changes in my \"Trace2 timers and cleanup and some\n> cleanup\" series on Tuesday, but pulled them into a separate series based on\n> feedback. I'll omit them from the trace2 series in the next version.\n\nThe expanded commit messages really help, thanks :)\n\nSo, to summarize, these don't fix compiler errors, but warnings, but of\ncourse they're errors with DEVELOPER=1.\n\nWe already squash these for an older GCC, per the discussion at [1]. I\nthink we should just replace this series with something like (untested\non OSX, but it's just copy/pasting a template above it).\n\t\n\tdiff --git a/config.mak.dev b/config.mak.dev\n\tindex 4fa19d361b7..9b7bccd154c 100644\n\t--- a/config.mak.dev\n\t+++ b/config.mak.dev\n\t@@ -69,6 +69,14 @@ DEVELOPER_CFLAGS += -Wno-missing-braces\n\t endif\n\t endif\n\t \n\t+ifeq ($(uname_S),Darwin)\n\t+ifneq ($(filter clang10,$(COMPILER_FEATURES)),)\n\t+ifeq ($(filter clang11,$(COMPILER_FEATURES)),)\n\t+DEVELOPER_CFLAGS += -Wno-missing-braces\n\t+endif\n\t+endif\n\t+endif\n\t+\n\t # https://bugzilla.redhat.com/show_bug.cgi?id=2075786\n\t ifneq ($(filter gcc12,$(COMPILER_FEATURES)),)\n\t DEVELOPER_CFLAGS += -Wno-error=stringop-overread\n\t\nOr, we can just say that for a <= clang v13 we'll use\n-Wno-missing-braces, per:\n\n * The comment from René at\n http://lore.kernel.org/git/36cd156b-edb2-062c-9422-bf39aad39a6d@web.de\n that older vanilla clang is affected.\n\n * You having tested Apple clang v14, but not clang v12..v13.\n\nI.e. to emit the whole uname_S bit.\n\nI think it's not important that we try really hard to opt a given\ncompiler into some maximum set of warnings, we generally want to catch\nmost things here. As long as some compiler (particularly if it's in CI)\nstill covers these we should be good.\n\n1. https://lore.kernel.org/git/220712.864jzm65mk.gmgdl@evledraar.gmail.com/\n"},{"id":"464381","messageId":"0f67ca77-f17f-d844-e689-ca9a9bdf7993@jeffhostetler.com","threadId":"58576","inReplyTo":"pull.1375.git.1665085395.gitgitgadget@gmail.com","subject":"Re: [PATCH 0/2] Fix syntax errors under clang 11.0.0 on MacOS","fromName":"Jeff Hostetler","fromEmail":"git@jeffhostetler.com","sentAt":"2022-10-07T15:19:19Z","receivedAt":"2022-10-07T15:19:24Z","isPatch":true,"sender":{"key":"git@jeffhostetler.com","avatar":null},"body":"\n\nOn 10/6/22 3:43 PM, Jeff Hostetler via GitGitGadget wrote:\n> This patch series fixes three syntax errors that caused compiler errors with\n> clang 11.0.0 on MacOS. I've included the error/warning messages in the\n> commit messages. The offending statements did compile successfully under\n> clang 14.0.0 on MacOS, so I have to assume that this usage is newer than\n> what clang 11 supports.\n[...]\n\nI didn't realize that these variable initialization fixes would\nspawn such a large response here [1]. Nor that it had been already\ndiscussed in great length in [2] in July.\n\nI'm not sure how to best proceed here.\n\n* I'm not sure these fixes are important enough to warrant the\n engineering time to hack up the Makefile or config.mak.uname\n to conditionally turn off -Wno-missing-braces based on some\n {platform-os-version, gcc/clang-version} combination.\n\n* While -Wno-missing-braces option may prevent the warning/error\n (depending on -Werror) for these \"{0}\" should be \"{{0}}\"\n errors, do we know that this won't hide real problems. (I mean\n we tend to only see it for these {0} / {{0}} false alarms, but\n I'd hate to lose the protection for non-false alarms.)\n\n* The suggestion to use a _INIT macro to hide the {0} or\n {{0}} may help in the:\n xmparam_t xmp = XMPARAM_INIT;\n case, but in the `mmfile_t mmfs[3]` case, we have an array of\n that type, so we'd need something like:\n mmfile_t mmfs[3] = { MMFILE_INIT }; or\n mmfile_t mmfs[3] = MMFILE_INIT_ARRAY;\n for the macros to make sense.\n I'm not sure either of these two is better than just writing \"{{0}}\".\n\n* I wasn't sure which compiler versions we *want* to support or\n want to drop support for.\n * I've only thought about it in the context of clang on MacOS.\n * Clang 11 (from what I can tell (without looking too hard))\n comes with the version of XCode that runs on MacOS 10.15\n Catalina. (In contrast, clang 14 comes with the version of\n XCode that runs on MacOS 12.6 Monterey.)\n * I can't comment on other old-ish compilers on other platforms.\n\n* I'm not the first one who has stumbled over this and had to\n rediscover the solution. So I'd hate to just kick this down\n the road some more, but then again I'd hate to waste a lot of\n time on it -- for very little actual functional value.\n\n* Is \"{{0}}\" really that ugly ???\n\nSo as I said earlier, I'm not sure how to proceed here.\n\nJeff\n\n\n[1] \nhttps://lore.kernel.org/git/pull.1375.git.1665085395.gitgitgadget@gmail.com/\n\n[2] \nhttps://lore.kernel.org/git/365e01e93dce582e9d926e83bdc6891310d22699.1659084832.git.congdanhqx@gmail.com/\n"},{"id":"464388","messageId":"xmqqpmf3frr5.fsf@gitster.g","threadId":"58576","inReplyTo":"0f67ca77-f17f-d844-e689-ca9a9bdf7993@jeffhostetler.com","subject":"Re: [PATCH 0/2] Fix syntax errors under clang 11.0.0 on MacOS","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-10-07T17:49:50Z","receivedAt":"2022-10-07T17:49:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff Hostetler writes:\n\n> I didn't realize that these variable initialization fixes would\n> spawn such a large response here [1]. Nor that it had been already\n> discussed in great length in [2] in July.\n>\n> I'm not sure how to best proceed here.\n>\n> * I'm not sure these fixes are important enough to warrant the\n> engineering time to hack up the Makefile or config.mak.uname\n> to conditionally turn off -Wno-missing-braces based on some\n> {platform-os-version, gcc/clang-version} combination.\n\nDevelopers are expected to be able to cope, but if this something a\nfew easy lines in config.mak.uname can help, we'd better do so,\ninstead of having dozens of folks on the macOS add the same line to\ntheir config.mak file.\n\n> * While -Wno-missing-braces option may prevent the warning/error\n> (depending on -Werror) for these \"{0}\" should be \"{{0}}\"\n> errors, do we know that this won't hide real problems. (I mean\n> we tend to only see it for these {0} / {{0}} false alarms, but\n> I'd hate to lose the protection for non-false alarms.)\n\nIt may find real problems, but folks on other platforms are running\nwithout the check disabled, so we should be OK. More importantly,\nfolks with a more recent compilers on macOS are running with the\ncheck, so we should be able to give a reasonable coverage to\nplatform specific code, too.\n\n> * The suggestion to use a _INIT macro to hide the {0} or\n> {{0}} may help in the:\n> xmparam_t xmp = XMPARAM_INIT;\n> case, but in the `mmfile_t mmfs[3]` case, we have an array of\n> that type, so we'd need something like:\n> mmfile_t mmfs[3] = { MMFILE_INIT }; or\n> mmfile_t mmfs[3] = MMFILE_INIT_ARRAY;\n> for the macros to make sense.\n> I'm not sure either of these two is better than just writing \"{{0}}\".\n\nI do not like that suggestion at all. I think it is the right\napproach to use -Wno-missing-braces with older and buggy compilers\nuntil they die out.\n\n> * I wasn't sure which compiler versions we *want* to support or\n> want to drop support for.\n> * I've only thought about it in the context of clang on MacOS.\n\nI think that is OK. IIRC, we have more or less good grasp on the\ncut-off version of clang as the upstream calls it, but the problem\nis clang shipped with macOS lies and gives a version number more\nrecent than it actually is.\n\n> * I'm not the first one who has stumbled over this and had to\n> rediscover the solution. So I'd hate to just kick this down\n> the road some more, but then again I'd hate to waste a lot of\n> time on it -- for very little actual functional value.\n\nExactly.\n\n> * Is \"{{0}}\" really that ugly ???\n\nUgly is not the issue. Folks on more recent platforms not being\nable to tell when to use the extra parentheses is, because their\ncompilers do not have this bug.\n\nMy preference is to flip the -Wno-missing-braces bit in\nconfig.mak.uname only for folks who use the version of clang on\nmacOS when that clang claims to be clang11 (my understanding of\nRené's experiment[*] is that versions of (real) clang 9 or newer\nperfectly well understand that {0} is an accpetable way to specify\nzero initialization for any structure, with possible nesting).\n\n[Reference]\n\n* https://lore.kernel.org/git/36cd156b-edb2-062c-9422-bf39aad39a6d@web.de/\n"},{"id":"464396","messageId":"ec920650-4334-a6f2-6d6f-241899dd79ec@web.de","threadId":"58576","inReplyTo":"xmqqpmf3frr5.fsf@gitster.g","subject":"Re: [PATCH 0/2] Fix syntax errors under clang 11.0.0 on MacOS","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2022-10-07T20:28:27Z","receivedAt":"2022-10-07T20:29:22Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 07.10.22 um 19:49 schrieb Junio C Hamano:\n>\n> My preference is to flip the -Wno-missing-braces bit in\n> config.mak.uname only for folks who use the version of clang on\n> macOS when that clang claims to be clang11 (my understanding of\n> René's experiment[*] is that versions of (real) clang 9 or newer\n> perfectly well understand that {0} is an accpetable way to specify\n> zero initialization for any structure, with possible nesting).\n>\n> [Reference]\n>\n> * https://lore.kernel.org/git/36cd156b-edb2-062c-9422-bf39aad39a6d@web.de/\n\nWikipedia has a map that says Apple calls the LLVM clang 8 (i.e. the\nreal one) \"11.0.0\" and clang 9 \"11.0.3\":\n\nhttps://en.wikipedia.org/wiki/Xcode#Xcode_11.0_-_14.x_(since_SwiftUI_framework)_2\n\nPerhaps like this? (No sign-off because I'm not comfortable with that\nmake function syntax, but feel free to steal salvageable parts.)\n\ndiff --git a/config.mak.dev b/config.mak.dev\nindex 4fa19d361b..4d59c9044f 100644\n--- a/config.mak.dev\n+++ b/config.mak.dev\n@@ -69,6 +69,14 @@ DEVELOPER_CFLAGS += -Wno-missing-braces\n endif\n endif\n\n+# LLVM clang older than 9 and Apple clang older than 12 complain\n+# about initializing a struct-within-a-struct using just \"{ 0 }\"\n+ifneq ($(filter clang1,$(COMPILER_FEATURES)),)\n+ifeq ($(filter $(if $(filter Darwin,$(uname_S)),clang12,clang9),$(COMPILER_FEATURES)),)\n+DEVELOPER_CFLAGS += -Wno-missing-braces\n+endif\n+endif\n+\n # https://bugzilla.redhat.com/show_bug.cgi?id=2075786\n ifneq ($(filter gcc12,$(COMPILER_FEATURES)),)\n DEVELOPER_CFLAGS += -Wno-error=stringop-overread\n\n"},{"id":"464397","messageId":"58d3ef47-2196-4f59-692a-fc86dfbc1252@jeffhostetler.com","threadId":"58576","inReplyTo":"ec920650-4334-a6f2-6d6f-241899dd79ec@web.de","subject":"Re: [PATCH 0/2] Fix syntax errors under clang 11.0.0 on MacOS","fromName":"Jeff Hostetler","fromEmail":"git@jeffhostetler.com","sentAt":"2022-10-07T20:56:01Z","receivedAt":"2022-10-07T20:56:07Z","isPatch":true,"sender":{"key":"git@jeffhostetler.com","avatar":null},"body":"\n\nOn 10/7/22 4:28 PM, René Scharfe wrote:\n> Am 07.10.22 um 19:49 schrieb Junio C Hamano:\n>>\n>> My preference is to flip the -Wno-missing-braces bit in\n>> config.mak.uname only for folks who use the version of clang on\n>> macOS when that clang claims to be clang11 (my understanding of\n>> René's experiment[*] is that versions of (real) clang 9 or newer\n>> perfectly well understand that {0} is an accpetable way to specify\n>> zero initialization for any structure, with possible nesting).\n>>\n>> [Reference]\n>>\n>> * https://lore.kernel.org/git/36cd156b-edb2-062c-9422-bf39aad39a6d@web.de/\n> \n> Wikipedia has a map that says Apple calls the LLVM clang 8 (i.e. the\n> real one) \"11.0.0\" and clang 9 \"11.0.3\":\n> \n> https://en.wikipedia.org/wiki/Xcode#Xcode_11.0_-_14.x_(since_SwiftUI_framework)_2\n> \n> Perhaps like this? (No sign-off because I'm not comfortable with that\n> make function syntax, but feel free to steal salvageable parts.)\n> \n> diff --git a/config.mak.dev b/config.mak.dev\n> index 4fa19d361b..4d59c9044f 100644\n> --- a/config.mak.dev\n> +++ b/config.mak.dev\n> @@ -69,6 +69,14 @@ DEVELOPER_CFLAGS += -Wno-missing-braces\n> endif\n> endif\n> \n> +# LLVM clang older than 9 and Apple clang older than 12 complain\n> +# about initializing a struct-within-a-struct using just \"{ 0 }\"\n> +ifneq ($(filter clang1,$(COMPILER_FEATURES)),)\n> +ifeq ($(filter $(if $(filter Darwin,$(uname_S)),clang12,clang9),$(COMPILER_FEATURES)),)\n> +DEVELOPER_CFLAGS += -Wno-missing-braces\n> +endif\n> +endif\n> +\n\nSo if I understand you correctly, Apple clang 11 is broken\nand Apple clang 12 is good.\n\nI was getting ready to send (as soon as the CI finished)\nthe following a simple to add the -Wno... for clang 11 and\nbelow on Darwin.\n\n+ifeq ($(uname_S),Darwin)\n+# Older versions of Apple clang complain about initializing a\n+# struct-within-a-struct using just \"{0}\" rather than \"{{0}}\".\n+# More recent versions do not. This error is considered a\n+# false-positive and not worth fixing, so just disable it.\n+ifeq ($(filter clang12,$(COMPILER_FEATURES)),)\n+DEVELOPER_CFLAGS += -Wno-missing-braces\n+endif\n+endif\n\nI'm not sure I understand all of what your suggestion does.\n\nJeff\n\n"},{"id":"464400","messageId":"xmqqy1trcof1.fsf@gitster.g","threadId":"58576","inReplyTo":"ec920650-4334-a6f2-6d6f-241899dd79ec@web.de","subject":"Re: [PATCH 0/2] Fix syntax errors under clang 11.0.0 on MacOS","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-10-07T21:30:10Z","receivedAt":"2022-10-07T21:30:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"René Scharfe writes:\n\n> Perhaps like this? (No sign-off because I'm not comfortable with that\n> make function syntax, but feel free to steal salvageable parts.)\n>\n> diff --git a/config.mak.dev b/config.mak.dev\n> index 4fa19d361b..4d59c9044f 100644\n> --- a/config.mak.dev\n> +++ b/config.mak.dev\n> @@ -69,6 +69,14 @@ DEVELOPER_CFLAGS += -Wno-missing-braces\n> endif\n> endif\n>\n> +# LLVM clang older than 9 and Apple clang older than 12 complain\n> +# about initializing a struct-within-a-struct using just \"{ 0 }\"\n> +ifneq ($(filter clang1,$(COMPILER_FEATURES)),)\n\nIf it is any version of clang, detect-compiler script should give us\nat last \"clang1\" in $(COMPILER_FEATURES), and filtering the latter\nwith \"clang1\" should become \"clang1\" which should be neq. We fail\nthe ifneq if the compiler is not llvm and do not come into this part.\n\n> +ifeq ($(filter $(if $(filter Darwin,$(uname_S)),clang12,clang9),$(COMPILER_FEATURES)),)\n\nOn Darwin, $(uname_S) is Darwin and filtering the $(uname_S) with\nDarwin will leave Darwin as the \"condition\" parameter to $(if).\nSo $(if) evaluates to clang12 on Darwin and clang9 everywhere else.\nIf $(COMPILER_FEATURES) lacks that cut-off version, that means we\nare using clang older than 12 (on macOS) or 9 (everywhere else) and\nwe come inside this block ...\n\n> +DEVELOPER_CFLAGS += -Wno-missing-braces\n\n... which adds this workaround.\n\n> +endif\n> +endif\n\nOK. That is dense, but sounds correct.\n\n"},{"id":"464401","messageId":"xmqqtu4fco9d.fsf@gitster.g","threadId":"58576","inReplyTo":"58d3ef47-2196-4f59-692a-fc86dfbc1252@jeffhostetler.com","subject":"Re: [PATCH 0/2] Fix syntax errors under clang 11.0.0 on MacOS","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-10-07T21:33:34Z","receivedAt":"2022-10-07T21:34:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff Hostetler writes:\n\n> So if I understand you correctly, Apple clang 11 is broken\n> and Apple clang 12 is good.\n>\n> I was getting ready to send (as soon as the CI finished)\n> the following a simple to add the -Wno... for clang 11 and\n> below on Darwin.\n>\n> +ifeq ($(uname_S),Darwin)\n> +# Older versions of Apple clang complain about initializing a\n> +# struct-within-a-struct using just \"{0}\" rather than \"{{0}}\".\n> +# More recent versions do not. This error is considered a\n> +# false-positive and not worth fixing, so just disable it.\n> +ifeq ($(filter clang12,$(COMPILER_FEATURES)),)\n> +DEVELOPER_CFLAGS += -Wno-missing-braces\n> +endif\n> +endif\n>\n> I'm not sure I understand all of what your suggestion does.\n\nI do agree that one is dense, but aims for the same thing, and a bit\nmore. It might be easier to read if written in longhand, but ...\n\nifeq ($(uname_s),Darwin)\nifeq ($(filter clang12,$(COMPILER_FEATURES)),)\nDEVELOPER_CFLAGS += -Wno-missing-braces\nendif\nelse\nifeq ($(filter clang9,$(COMPILER_FEATURES)),)\nDEVELOPER_CFLAGS += -Wno-missing-braces\nendif\nendif\n\n... we'd need to repeat ourselves, so...\n"},{"id":"464412","messageId":"CAPig+cS=k80JdCBAHbSqcOUBc=iGDetoT3u84oRj2CKpFs7CGg@mail.gmail.com","threadId":"58576","inReplyTo":"xmqqtu4fco9d.fsf@gitster.g","subject":"Re: [PATCH 0/2] Fix syntax errors under clang 11.0.0 on MacOS","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2022-10-08T03:46:27Z","receivedAt":"2022-10-08T03:46:42Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, Oct 7, 2022 at 5:36 PM Junio C Hamano wrote:\n> I do agree that one is dense, but aims for the same thing, and a bit\n> more. It might be easier to read if written in longhand, but ...\n>\n> ifeq ($(uname_s),Darwin)\n> ifeq ($(filter clang12,$(COMPILER_FEATURES)),)\n> DEVELOPER_CFLAGS += -Wno-missing-braces\n> endif\n> else\n> ifeq ($(filter clang9,$(COMPILER_FEATURES)),)\n> DEVELOPER_CFLAGS += -Wno-missing-braces\n> endif\n> endif\n>\n> ... we'd need to repeat ourselves, so...\n\nThe repetition is a very minor downside. The big benefit of this\nversion is that it's easy to understand at-a-glance, unlike the\n\"dense\" version with its high cognitive load.\n"},{"id":"464418","messageId":"a8b83ff1-97b6-e2d2-91c7-ace597013368@web.de","threadId":"58576","inReplyTo":"CAPig+cS=k80JdCBAHbSqcOUBc=iGDetoT3u84oRj2CKpFs7CGg@mail.gmail.com","subject":"Re: [PATCH 0/2] Fix syntax errors under clang 11.0.0 on MacOS","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2022-10-08T06:52:01Z","receivedAt":"2022-10-08T06:53:00Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 08.10.22 um 05:46 schrieb Eric Sunshine:\n> On Fri, Oct 7, 2022 at 5:36 PM Junio C Hamano wrote:\n>> I do agree that one is dense, but aims for the same thing, and a bit\n>> more. It might be easier to read if written in longhand, but ...\n>>\n>> ifeq ($(uname_s),Darwin)\n>> ifeq ($(filter clang12,$(COMPILER_FEATURES)),)\n>> DEVELOPER_CFLAGS += -Wno-missing-braces\n>> endif\n>> else\n>> ifeq ($(filter clang9,$(COMPILER_FEATURES)),)\n>> DEVELOPER_CFLAGS += -Wno-missing-braces\n>> endif\n>> endif\n>>\n>> ... we'd need to repeat ourselves, so...\n>\n> The repetition is a very minor downside. The big benefit of this\n> version is that it's easy to understand at-a-glance, unlike the\n> \"dense\" version with its high cognitive load.\n\nIt's certainly easier.\n\nIt triggers for any compiler that is not clang, though, which is\na bit much. Alternative compilers may not even understand that\nflag. So the whole thing should be wrapped in\n\n ifneq ($(filter clang1,$(COMPILER_FEATURES)),)\n ...\n endif\n\nor\n\n ifneq ($(filter clang%,$(COMPILER_FEATURES)),)\n ...\n endif\n\nRené\n"},{"id":"464439","messageId":"xmqqr0zh8tg7.fsf@gitster.g","threadId":"58576","inReplyTo":"a8b83ff1-97b6-e2d2-91c7-ace597013368@web.de","subject":"Re: [PATCH 0/2] Fix syntax errors under clang 11.0.0 on MacOS","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-10-09T05:19:36Z","receivedAt":"2022-10-09T05:32:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"René Scharfe writes:\n\n> Am 08.10.22 um 05:46 schrieb Eric Sunshine:\n>> On Fri, Oct 7, 2022 at 5:36 PM Junio C Hamano wrote:\n>>> I do agree that one is dense, but aims for the same thing, and a bit\n>>> more. It might be easier to read if written in longhand, but ...\n>>>\n>>> ifeq ($(uname_s),Darwin)\n>>> ifeq ($(filter clang12,$(COMPILER_FEATURES)),)\n>>> DEVELOPER_CFLAGS += -Wno-missing-braces\n>>> endif\n>>> else\n>>> ifeq ($(filter clang9,$(COMPILER_FEATURES)),)\n>>> DEVELOPER_CFLAGS += -Wno-missing-braces\n>>> endif\n>>> endif\n>>>\n>>> ... we'd need to repeat ourselves, so...\n>>\n>> The repetition is a very minor downside. The big benefit of this\n>> version is that it's easy to understand at-a-glance, unlike the\n>> \"dense\" version with its high cognitive load.\n>\n> It's certainly easier.\n>\n> It triggers for any compiler that is not clang, though, which is\n> a bit much.\n\nYeah, of course you are right. In my \"here is a translation to\nhuman-language\" I did explain what \"clang1\" was doing in your\nversion, but of course, I forgot all about it when writing the above\nvariant.\n"},{"id":"464479","messageId":"pull.1375.v2.git.1665416340806.gitgitgadget@gmail.com","threadId":"58576","inReplyTo":"pull.1375.git.1665085395.gitgitgadget@gmail.com","subject":"[PATCH v2] config.mak.dev: disable suggest braces error on old clang versions","fromName":"Jeff Hostetler via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-10-10T15:39:00Z","receivedAt":"2022-10-10T15:39:09Z","isPatch":true,"sender":{"key":"git@jeffhostetler.com","avatar":null},"body":"From: Jeff Hostetler \n\nAdd the \"-Wno-missing-braces\" option when building with an old version\nof clang to suppress the \"suggest braces around initialization\" error\nin developer mode.\n\nFor example, using an old version of clang gives the following errors\n(when in DEVELOPER=1 mode):\n\n$ make builtin/merge-file.o\n CC builtin/merge-file.o\nbuiltin/merge-file.c:29:23: error: suggest braces around initialization \\\n\t\t\t of subobject [-Werror,-Wmissing-braces]\n mmfile_t mmfs[3] = { 0 };\n ^\n {}\nbuiltin/merge-file.c:31:20: error: suggest braces around initialization \\\n\t\t\t of subobject [-Werror,-Wmissing-braces]\n xmparam_t xmp = { 0 };\n ^\n {}\n2 errors generated.\n\nThis example compiles without error/warning with updated versions of\nclang. Since this is an obsolete error, use the -Wno-missing-braces\noption to silence the warning when using an older compiler. This\navoids the need to update the code to use \"{{0}}\" style\ninitializations.\n\nUpstream clang version 8 has the problem. It was fixed in version 9.\n\nThe version of clang distributed by Apple with XCode has its own\nunique set of version numbers. Apple clang version 11 has the\nproblem. It was fixed in version 12.\n\nSigned-off-by: Jeff Hostetler \n---\n Fix syntax errors under clang 11.0.0 on MacOS\n \n Here is version 2. This version adds the \"-Wno-missing-braces\" compiler\n flag when we are using an old version of clang -- rather than updating\n the source files to use the \"{{0}}\" syntax that was expected by older\n versions of clang.\n \n I've expanded the scope to include fixes for Apple's clang 11 and below\n and non-Apple clang 8 and below.\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-1375%2Fjeffhostetler%2Ffix-clang11-warnings-v2\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1375/jeffhostetler/fix-clang11-warnings-v2\nPull-Request: https://github.com/gitgitgadget/git/pull/1375\n\nRange-diff vs v1:\n\n 1: 7cee38788a7 < -: ----------- builtin/merge-file: fix compiler error on MacOS with clang 11.0.0\n 2: e5009a325f2 < -: ----------- builtin/unpack-objects.c: fix compiler error on MacOS with clang 11.0.0\n -: ----------- > 1: c6708ed9459 config.mak.dev: disable suggest braces error on old clang versions\n\n\n config.mak.dev | 25 +++++++++++++++++++++++++\n 1 file changed, 25 insertions(+)\n\ndiff --git a/config.mak.dev b/config.mak.dev\nindex 4fa19d361b7..981304727c5 100644\n--- a/config.mak.dev\n+++ b/config.mak.dev\n@@ -69,6 +69,31 @@ DEVELOPER_CFLAGS += -Wno-missing-braces\n endif\n endif\n \n+# Old versions of clang complain about initializaing a\n+# struct-within-a-struct using just \"{0}\" rather than \"{{0}}\". This\n+# error is considered a false-positive and not worth fixing, because\n+# new clang versions do not, so just disable it.\n+#\n+# The \"bug\" was fixed in upstream clang 9.\n+#\n+# Complicating this is that versions of clang released by Apple have\n+# their own version numbers (associated with the corresponding version\n+# of XCode) unrelated to the official clang version numbers.\n+#\n+# The bug was fixed in Apple clang 12.\n+#\n+ifneq ($(filter clang1,$(COMPILER_FEATURES)),) # if we are using clang\n+ifeq ($(uname_S),Darwin) # if we are on darwin\n+ifeq ($(filter clang12,$(COMPILER_FEATURES)),) # if version < 12\n+DEVELOPER_CFLAGS += -Wno-missing-braces\n+endif\n+else # not darwin\n+ifeq ($(filter clang9,$(COMPILER_FEATURES)),) # if version < 9\n+DEVELOPER_CFLAGS += -Wno-missing-braces\n+endif\n+endif\n+endif\n+\n # https://bugzilla.redhat.com/show_bug.cgi?id=2075786\n ifneq ($(filter gcc12,$(COMPILER_FEATURES)),)\n DEVELOPER_CFLAGS += -Wno-error=stringop-overread\n\nbase-commit: 3dcec76d9df911ed8321007b1d197c1a206dc164\n-- \ngitgitgadget\n"},{"id":"464515","messageId":"xmqqo7uj35td.fsf@gitster.g","threadId":"58576","inReplyTo":"pull.1375.v2.git.1665416340806.gitgitgadget@gmail.com","subject":"Re: [PATCH v2] config.mak.dev: disable suggest braces error on old clang versions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-10-10T18:13:34Z","receivedAt":"2022-10-10T18:13:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Jeff Hostetler via GitGitGadget\" writes:\n\n> Here is version 2. This version adds the \"-Wno-missing-braces\" compiler\n> flag when we are using an old version of clang -- rather than updating\n> the source files to use the \"{{0}}\" syntax that was expected by older\n> versions of clang.\n> \n> I've expanded the scope to include fixes for Apple's clang 11 and below\n> and non-Apple clang 8 and below.\n>\n> diff --git a/config.mak.dev b/config.mak.dev\n> index 4fa19d361b7..981304727c5 100644\n> --- a/config.mak.dev\n> +++ b/config.mak.dev\n> @@ -69,6 +69,31 @@ DEVELOPER_CFLAGS += -Wno-missing-braces\n> endif\n> endif\n> \n> +# Old versions of clang complain about initializaing a\n> +# struct-within-a-struct using just \"{0}\" rather than \"{{0}}\". This\n> +# error is considered a false-positive and not worth fixing, because\n> +# new clang versions do not, so just disable it.\n> +#\n> +# The \"bug\" was fixed in upstream clang 9.\n> +#\n> +# Complicating this is that versions of clang released by Apple have\n> +# their own version numbers (associated with the corresponding version\n> +# of XCode) unrelated to the official clang version numbers.\n> +#\n> +# The bug was fixed in Apple clang 12.\n> +#\n> +ifneq ($(filter clang1,$(COMPILER_FEATURES)),) # if we are using clang\n> +ifeq ($(uname_S),Darwin) # if we are on darwin\n> +ifeq ($(filter clang12,$(COMPILER_FEATURES)),) # if version < 12\n> +DEVELOPER_CFLAGS += -Wno-missing-braces\n> +endif\n> +else # not darwin\n> +ifeq ($(filter clang9,$(COMPILER_FEATURES)),) # if version < 9\n> +DEVELOPER_CFLAGS += -Wno-missing-braces\n> +endif\n> +endif\n> +endif\n\nLooks very straight-forward, albeit a tad verbose, and simple to\nfollow. I think this is equivalent to René's original one-liner.\n\nWill queue. Thanks.\n"},{"id":"464549","messageId":"xmqqtu4bxlka.fsf@gitster.g","threadId":"58576","inReplyTo":"xmqqo7uj35td.fsf@gitster.g","subject":"Re: [PATCH v2] config.mak.dev: disable suggest braces error on old clang versions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-10-11T00:15:17Z","receivedAt":"2022-10-11T00:15:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Looks very straight-forward, albeit a tad verbose, and simple to\n> follow. I think this is equivalent to René's original one-liner.\n>\n> Will queue. Thanks.\n\nFunny that during the whole time we were discussing this patch, I\nnever recalled b53a5f24 (config.mak.dev: squelch -Wno-missing-braces\nfor older gcc, 2022-07-29), which was a moral equivalent of this\nchange for older GCC, until I needed to decide the name of the topic\nbranch to queue this patch.\n\nI had the topic branch jk/struct-zero-init-with-older-gcc for\nb53a5f24 still lying around. I reused a part of its name and queued\nit on jh/struct-zero-init-with-older-clang branch.\n\n\n"}]}