Anonymous `struct` can not be selected by decl name "struct"

[dschrempf]

hs-bindgen offers selection by declaration name. For example, using the client option --select-by-decl-name. We also offer to select declarations by name kind (I am not sure if this is documented anywhere). For example, to select all structures, one can run

(C) $ cabal run -- hs-bindgen-cli preprocess -I ./ select-test.h --select-by-decl-name struct

Now, if select-test.h is

struct nested_outer_s {
  struct {
    int inner_member;
  } nested_inner_s;
};

We get an error:

[Error  ] [HsBindgen] [mangle-names] Missing declaration: 'struct nested_outer_s_nested_inner_s'; did you select the declaration?

This is because anonymous declarations are only matched against their name (prefixed with "anon:", which seems also pretty arbitrary). That is, we do not match against the name kind prefix.

In this case, the two strings we match against are:

"anon:nested_outer_s_nested_inner_s"
"struct nested_outer_s"

and only the second one gets selected. The first one is missing, as the error reports.

This may be a none-issue, but I think we should at least decide what we do in these cases.

[TravisCardwell]

We also offer to select declarations by name kind

This is the first I have heard of this. I do not think this should be done using --select-by-decl-name if we want to implement it.

prefixed with "anon:"

Anonymous names are now prefixed with @, right? anon: should be gone.

[dschrempf]

Maybe I have to rebase, but on my branch it is still anon:.

If we do not want to match for these prefixes, that would greatly simplify the select match predicate function; and then we do not have to thread through the decl kind when delaying parse messages (I think). @edsko .

[dschrempf]

qualDeclIdText :: QualDeclId -> Text
qualDeclIdText QualDeclId{..} = case qualDeclIdOrigin of
    NameOriginGenerated{} -> "anon:" <> getName qualDeclIdName
    _otherwise -> qualNameText $ QualName qualDeclIdName qualDeclIdKind

(And this is what we match against, at the moment).

[dschrempf]

I think we have to decide: "Is selection by declaration kind (e.g., structs) a use case?"

If not, let's match against decl name only. It simplifies things greatly.

If yes, I think we should add another constructor to the DeclPredicate:

newtype DeclPredicate =
    -- | Match declaration name against regex
    DeclNameMatches Regex
    -- This one:
  | Decl(Name)KindMatches
  deriving (Show, Eq)

(and fix how we match DeclNameMatches).

Related: #905

[TravisCardwell]

The change to use @ is pending in PR #960. We have to implement proper handling of anonymous declarations in binding specifications before we can merge.

[TravisCardwell]

I think we have to decide: "Is selection by declaration kind (e.g., structs) a use case?"

If not, let's match against decl name only. It simplifies things greatly.

I do not think that is a good idea. struct foo and foo are different declarations. It is critical that we distinguish them in binding specifications, and we should be consistent in selection predicates.

If yes, I think we should add another constructor to the DeclPredicate:

I agree that we should have a separate option for matching by kind, if it is needed.

[edsko]

I think there is confusion here. I don't think we (intend to) offer "selection by kind", we do need to know the kind, because the name ("C spelling") might be used to distinguish between (function) foo and struct foo.

[dschrempf]

Yes, we need to know the kind, but, as far as I can see, not when we match the select predicate. If we just match against the name foo, there is no need to know if we match agaisnt the function foo or the struct struct foo.

Or, do you mean the actual C name is struct foo?. Then this issue is relevant, because people will expect to be able to select all structs using the decl select predicate "struct". (And I still think we should then separate the predicate into DeclMatchesName and DeclMatchesKind).

[dschrempf]

Clarified in a meeting:

• The C name of a structure with identifier foo is struct foo, so we need to match against name kinds.
• We explicitly do not want to offer selecting declarations by name kind. This is only a side effect of C names including name kinds.
• @TravisCardwell tries to prefix the name of anonymous declarations with their name kind.

Closing this issue.