Re: [PATCH 0/2] Fix syntax errors under clang 11.0.0 on MacOS

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Oct 7, 2022, 11:02 UTC
Message-ID: <221007.861qrjriul.gmgdl@evledraar.gmail.com>
In-Reply-To: <pull.1375.git.1665085395.gitgitgadget@gmail.com>

On Thu, Oct 06 2022, Jeff Hostetler via GitGitGadget wrote:

Show 9 quoted lines

> This patch series fixes three syntax errors that caused compiler errors with
> clang 11.0.0 on MacOS. I've included the error/warning messages in the
> commit messages. The offending statements did compile successfully under
> clang 14.0.0 on MacOS, so I have to assume that this usage is newer than
> what clang 11 supports.
>
> I originally sent these changes in my "Trace2 timers and cleanup and some
> cleanup" series on Tuesday, but pulled them into a separate series based on
> feedback. I'll omit them from the trace2 series in the next version.

The expanded commit messages really help, thanks :)

So, to summarize, these don't fix compiler errors, but warnings, but of course they're errors with DEVELOPER=1.

We already squash these for an older GCC, per the discussion at [1]. I
think we should just replace this series with something like (untested
on OSX, but it's just copy/pasting a template above it).
	
	diff --git a/config.mak.dev b/config.mak.dev
	index 4fa19d361b7..9b7bccd154c 100644
	--- a/config.mak.dev
	+++ b/config.mak.dev
	@@ -69,6 +69,14 @@ DEVELOPER_CFLAGS += -Wno-missing-braces
	 endif
	 endif
	 
	+ifeq ($(uname_S),Darwin)
	+ifneq ($(filter clang10,$(COMPILER_FEATURES)),)
	+ifeq ($(filter clang11,$(COMPILER_FEATURES)),)
	+DEVELOPER_CFLAGS += -Wno-missing-braces
	+endif
	+endif
	+endif
	+
	 # https://bugzilla.redhat.com/show_bug.cgi?id=2075786
	 ifneq ($(filter gcc12,$(COMPILER_FEATURES)),)
	 DEVELOPER_CFLAGS += -Wno-error=stringop-overread
	
Or, we can just say that for a <= clang v13 we'll use
-Wno-missing-braces, per:

 * The comment from René at
   http://lore.kernel.org/git/36cd156b-edb2-062c-9422-bf39aad39a6d@web.de
   that older vanilla clang is affected.

 * You having tested Apple clang v14, but not clang v12..v13.

I.e. to emit the whole uname_S bit.

I think it's not important that we try really hard to opt a given compiler into some maximum set of warnings, we generally want to catch most things here. As long as some compiler (particularly if it's in CI) still covers these we should be good.

1. https://lore.kernel.org/git/220712.864jzm65mk.gmgdl@evledraar.gmail.com/