# [PATCH v2 0/1] Pedantic fix for Apple clang

3 messages from 2018-07-25 to 2018-07-26. Participants: Beat Bolli, Jonathan Nieder.
Thread: https://gitlist.dev/t/48956

## Beat Bolli, 2018-07-25 21:56

Subject: [PATCH v2 0/1] Pedantic fix for Apple clang
Message-ID: <20180725215607.19910-1-dev+git@drbeat.li>
URL: https://gitlist.dev/e/20180725215607.19910-1-dev%2Bgit%40drbeat.li

```
Following up on my previous series bb/pedantic for gcc, this is a fix
for pedantic compilation under MacOS 10.13.6 (High Sierra) with the
command line tools of Xcode Version 9.4.1 (9F2000).

Changes against v1:

- [1/2]: include cache.h in packfile.h.

- [2/2]: drop it. Christian Couder is going to include this in the next
  version of the cc/remote-odb topic.

Beat Bolli (1):
  packfile: drop a repeated enum declaration

 packfile.h   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.18.0


```

## Beat Bolli, 2018-07-25 21:56

Subject: [PATCH v2] packfile: ensure that enum object_type is defined
Message-ID: <20180725215607.19910-2-dev+git@drbeat.li>
URL: https://gitlist.dev/e/20180725215607.19910-2-dev%2Bgit%40drbeat.li
In-Reply-To: <20180725215607.19910-1-dev+git@drbeat.li>

```
When compiling under Apple LLVM version 9.1.0 (clang-902.0.39.2) with
"make DEVELOPER=1 DEVOPTS=pedantic", the compiler says

    error: redeclaration of already-defined enum 'object_type' is a GNU
    extension [-Werror,-Wgnu-redeclared-enum]

According to https://en.cppreference.com/w/c/language/declarations
(section "Redeclaration"), a repeated declaration after the definition
is only legal for structs and unions, but not for enums.

Drop the belated declaration of enum object_type and include cache.h
instead to make sure the enum is defined.

Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Beat Bolli <dev+git@drbeat.li>
---
 packfile.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/packfile.h b/packfile.h
index 51383774ec72..28318c5c7c42 100644
--- a/packfile.h
+++ b/packfile.h
@@ -1,12 +1,12 @@
 #ifndef PACKFILE_H
 #define PACKFILE_H
 
+#include "cache.h"
 #include "oidset.h"
 
 /* in object-store.h */
 struct packed_git;
 struct object_info;
-enum object_type;
 
 /*
  * Generate the filename to be used for a pack file with checksum "sha1" and
-- 
2.18.0


```

## Jonathan Nieder, 2018-07-26 00:44

Subject: Re: [PATCH v2] packfile: ensure that enum object_type is defined
Message-ID: <20180726004400.GA217613@aiede.svl.corp.google.com>
URL: https://gitlist.dev/e/20180726004400.GA217613%40aiede.svl.corp.google.com
In-Reply-To: <20180725215607.19910-2-dev+git@drbeat.li>

```
Beat Bolli wrote:

> When compiling under Apple LLVM version 9.1.0 (clang-902.0.39.2) with
> "make DEVELOPER=1 DEVOPTS=pedantic", the compiler says
>
>     error: redeclaration of already-defined enum 'object_type' is a GNU
>     extension [-Werror,-Wgnu-redeclared-enum]
>
> According to https://en.cppreference.com/w/c/language/declarations
> (section "Redeclaration"), a repeated declaration after the definition
> is only legal for structs and unions, but not for enums.
>
> Drop the belated declaration of enum object_type and include cache.h
> instead to make sure the enum is defined.
>
> Helped-by: Jonathan Nieder <jrnieder@gmail.com>
> Signed-off-by: Beat Bolli <dev+git@drbeat.li>
> ---
>  packfile.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Thanks!  I had run into this using clang on Linux, too, but hadn't
spent the time to track it down and write a patch.

Running

	git grep -e 'enum [^ ]*;'

doesn't find any other instances of this error.  Thanks for fixing it.

Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>

By the way, not about this patch:

[...]
> +++ b/packfile.h
> @@ -1,12 +1,12 @@
>  #ifndef PACKFILE_H
>  #define PACKFILE_H
>  
> +#include "cache.h"
>  #include "oidset.h"
>  
>  /* in object-store.h */
>  struct packed_git;
>  struct object_info;
> -enum object_type;

This '/* in object-store.h */' comment can easily go stale since
nothing enforces that it stays accurate.  I don't think it's a useful
comment to have anyway, since it's straightforward to grep for where
the struct is defined.  I think we should remove the comment.

Thanks,
Jonathan

```
