New Issue: c2chapel balks when formal argument name matches 'struct' name

Notifications Issues
1

18176, "bradcray", "c2chapel balks when formal argument name matches 'struct' name", "2021-08-06T18:03:10Z"

The following C header is legal:

#include <stdio.h>

struct mystruct {
  int x;
};

static void foo(struct mystruct mystruct) {
  printf("In foo()");
}

but today, gets converted by c2chapel into:

extern record mystruct {
  var x : c_int;
}

extern proc foo(in mystruct : mystruct) : void;

which is not legal Chapel because the formal argument name and its type name match, yielding the following (which I consider to be correct / appropriate behavior):

testit.chpl:13: In function 'foo':
testit.chpl:13: error: 'mystruct' used before defined
testit.chpl:13: note: defined here

This issue asks whether this is something that c2chapel should take care of, or whether it's the sort of thing that we'd say the user of c2chapel should have to manually massage / fix in the generated .chpl code.

Some ways that c2chapel could handle it:

  • if it finds that a type and argument match in name, it could rename the argument name without having a major impact (since C doesn't support pass-by-keyword). This would help with this specific case, but wouldn't help with other cases in which, say, there was a conflict between the types/names of an earlier and later argument. It's slightly unfortunate in that it'd be nice for the Chapel programmer to have the argument name match the C when possible.
  • it could always generate struct s type names as struct_s. I like this approach because it preserves the formal name, and makes the Chapel type name closer to the C name (struct s). However, note that while this would help with this specific case, it of course may not help with others (e.g., I believe C permits an argument of type and name t; or perhaps the C header actually defined a symbol named struct_s elsewhere that we've just created a second declaration of).

I'm also OK with the status quo and requiring the user to curate the output and make these decisions if we decided that a c2chapel-based fix would be opening up more cans of worms than it solves.

This is a case that @bmcdonald3 ran into when running Apache Arrow / Parquet files through c2chapel.