Support "eponymous" macros

[jorisdral]

From: #991 (comment)

These macro "newtypes" redefine an existing identifier as a macro, but the macro simply desugars to the pre-exesting identifier. Such cases exis in the wild, for example in stdio.h:

typedef int FILE;

extern FILE *const stdin;
extern FILE *const stdout;
extern FILE *const stderr;

#define stdin  (stdin)
#define stdout (stdout)
#define stderr (stderr)

The current behaviour of hs-bindgen is to not generate a binding and emit a "redeclaration" trace message. Should hs-bindgen instead allow this corner-case of a redeclared identifier, and generate a binding for the non-macro declaration?

[edsko]

I'm going to mark this as a low priority enhancement for now, until we run into this in the wild. I suspect we won't see this pattern in anything but the lowest level of headers. Right now the behaviour is merely that we don't generate a binding, and I think that's sensible enough in general.

[dschrempf]

Found another one of those ...

// posix_types_64.h
/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
#ifndef _ASM_X86_POSIX_TYPES_64_H
#define _ASM_X86_POSIX_TYPES_64_H

/*
 * This file is generally used by user-level software, so you need to
 * be a little careful about namespace pollution etc.  Also, we cannot
 * assume GCC is being used.
 */

typedef unsigned short __kernel_old_uid_t;
typedef unsigned short __kernel_old_gid_t;
#define __kernel_old_uid_t __kernel_old_uid_t

typedef unsigned long	__kernel_old_dev_t;
#define __kernel_old_dev_t __kernel_old_dev_t

#include <asm-generic/posix_types.h>

#endif /* _ASM_X86_POSIX_TYPES_64_H */

Crashes libpcap translation with the following error:

PANIC!: the impossible happened
Please report this as a bug at https://github.com/well-typed/hs-bindgen/issues/
DeclIndex.fromParseResults: shared keys: fromList [QualPrelimDeclIdNamed "__kernel_old_dev_t" NameKindOrdinary,QualPrelimDeclIdNamed "__kernel_old_uid_t" NameKindOrdinary]
CallStack (from HasCallStack):
  panicPure, called at src-internal/HsBindgen/Frontend/Analysis/DeclIndex.hs:84:13 in hs-bindgen-0.1.0-B1FiWxBXv3WE1UHxtVuRyX-internal:HsBindgen.Frontend.Analysis.DeclIndex

One of the declaration in question is in succeeded and omitted:

  ,(
      QualPrelimDeclIdNamed "__kernel_old_dev_t" NameKindOrdinary
    ,ParseSuccess {
        psDecl = Decl {
          declInfo = DeclInfo {
            declLoc = "/nix/store/0vqrw0y515015i3065r9s00jcp1cd4hy-glibc-2.40-66-dev/include/asm/posix_types_64.h:15:23"
          , declId = PrelimDeclIdNamed "__kernel_old_dev_t"
          , declAliases = []
          , declHeaderInfo = Just (
              HeaderInfo {
                headerMainHeaders = HashIncludeArg {getHashIncludeArg = "pcap.h"} :| []
              , headerInclude = HashIncludeArg {getHashIncludeArg = "asm/posix_types_64.h"}
            }
          )
          , declAvailability = Available
          , declComment = Nothing
        }
        , declKind = DeclTypedef (
            Typedef {
              typedefType = TypePrim (PrimIntegral PrimLong Unsigned)
            , typedefAnn = ReparseNotNeeded
          }
        )
        , declAnn = NoAnn
      }
      , psAttachedMsgs = []
    }
  )


  ,(
      QualPrelimDeclIdNamed "__kernel_old_dev_t" NameKindOrdinary
    ,ParseNotAttempted {
        poQualPrelimDeclId = QualPrelimDeclIdNamed "__kernel_old_dev_t" NameKindOrdinary
      , poSingleLoc = "/nix/store/0vqrw0y515015i3065r9s00jcp1cd4hy-glibc-2.40-66-dev/include/asm/posix_types_64.h:16:9"
      , poAvailability = Available
      , poParseNotAttemptedReason = ParsePredicateNotMatched
    } :| []
  )

(I think the same is true for the other one).

[dschrempf]

@edsko should we change priority here? Panicking here is pretty bad, and users will be confused.

[jorisdral]

I should have probably posted this here earlier: What I know from the

extern FILE *const stdin;
#define stdin  (stdin)

example is that they do this because in older C revisions it was specified that stdin should be a macro. So, this is a way to make sure they still satisfy that older spec even if the macro immediately expands to an extern definition.

Something similar might be going on with the error you're seeing @dschrempf

[TravisCardwell]

Perhaps an easy workaround would be to check for this case and ignore the same-name macro definition? I doubt we would ever want distinct bindings for this...

[edsko]

@edsko should we change priority here? Panicking here is pretty bad, and users will be confused.

We definitely should not panic. The priority on this ticket was low because we weren't panicking before, we were simply omitting the declaration (both of them, in fact, conservatively). But I agree with @TravisCardwell that it would probably make sense to special case the same-name-macro and then ignore the macro.

[dschrempf]

The panic is relatively new, now that we distinguish between succeeded, failed, and omitted.

[edsko]

Let's address this by ignoring the macro if we have also a declaration of the same name.