Should we panic on unbound typedefs?

[dschrempf]

Right now, when we get the underlying type of a typedef, we panic if the typedef is not available (i.e., unbound). This happens in the function getUnderlyingType in Translation.hs.

However, there could be situations where this is actually the case. Consider the minimal example

typedef int foo;
extern const foo x;

If we do not select foo, the typedef is unavailable. At the moment, we do not emit the panic because hs-bindgen already fails earlier reporting:

$ cabal run -- hs-bindgen-cli preprocess -I ./ c.h --select-by-decl-name x
...
[Error  ] [HsBindgen] [mangle-names] Missing declaration: 'foo'; did you select the declaration?
An error happend (see above)
...

However, we should still make a conscious decision if we want to keep this panic. There is also a corresponding TODO note in the code.

[jorisdral]

While in the hs-bindgen backend we might not have information available about all typedefs in a header, clang probably does have a lot of information that we could use. For example, we could use clang_getCanonicalType to erase typedefs. And maybe clang_getTypeDeclaration can help us construct mappings of typedefs to types

• clang_getTypeDeclaration
• clang_getCanonicalType

[dschrempf]

I think both of these links pint to clang_getTypeDeclaration;
clang_getCanonicalType sounds very interesting though!

AFAIK, we only want to use these function in the parse pass. Do you think we should annotate all typedefs with their underlying type already in that pass?

[jorisdral]

I'm on the fence about how best to use these functions. I've tried annotating typedefs with their canonical type, but this wasn't as straightforward as I had hoped when passing these typedefs through all the frontend passes. Also, getCanonicalType removes all sugar for us. It might be more useful if we can control how much sugar and which sugar (typedefs, const qualifiers) to remove. It's sometimes hard to recover the connection between a type and its canonical version after the fact.

Something else I considered but didn't try was that we could build a mapping of all typedef names (that are used in a header) to types in the parse pass as an additional parse result. We have a similar mapping now, but it only includes typedefs that we have selected for binding generation. It seems doable that we can create such a mapping for all used typedefs. And maybe with clang_getTypeDeclaration we can do that?

[edsko]

Having discussed this with @jorisdral , we will address this by annotating all (selected) typedef use sites with their underlying type. This means that we do not need to pass any out of bounds Map anymore, ensuring that we have the information right where we need it, and that it must always be present.

We do need to be cautious using this information: the annotation is a C type for which we may not have a Haskell type. @dschrempf , @TravisCardwell , thoughts on that particular issue?

[TravisCardwell]

Sounds good.

I guess a typedef use site for which the annotation does not have a corresponding Haskell type must be opaque (and therefore only valid by reference)?

[edsko]

I guess a typedef use site for which the annotation does not have a corresponding Haskell type must be opaque (and therefore only valid by reference)?

I think that makes sense, yes.