Using Generic reactors with custom types

[erlingrj]

I am unable to compile LF programs with generic reactors whose generic type is not included by the generic reactor. Consider this example costing of two source files:

Generic.lf

target CCpp
reactor Generic<T> {
  input in: T
  output out: T
  reaction(in) -> out {=
    out->value = in->value;
  =}
}

UseGeneric.lf

target CCpp
import Generic from "./Generic.lf"
preamble {=
  typedef int my_type_t;
=}
main reactor {
  r = new Generic<my_type_t>()
}

This results in this error:

In file included from /home/erling/dev/lf-ex/src-gen/UseGeneric/UseGeneric.cpp:22:
/home/erling/dev/lf-ex/src-gen/UseGeneric/_genericmy_type_t.h:15:5: error: ‘my_type_t’ does not name a type; did you mean ‘idtype_t’?
   15 |     my_type_t value;
      |     ^~~~~~~~~
      |     idtype_t
/home/erling/dev/lf-ex/src-gen/UseGeneric/_genericmy_type_t.h:29:5: error: ‘my_type_t’ does not name a type; did you mean ‘idtype_t’?
   29 |     my_type_t value;
      |     ^~~~~~~~~
      |     idtype_t
make[2]: *** [CMakeFiles/UseGeneric.dir/build.make:118: CMakeFiles/UseGeneric.dir/UseGeneric.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
In file included from /home/erling/dev/lf-ex/src-gen/UseGeneric/_genericmy_type_t.cpp:5:
/home/erling/dev/lf-ex/src-gen/UseGeneric/include/Generic/Genericmy_type_t.h:29:5: error: ‘my_type_t’ does not name a type; did you mean ‘idtype_t’?
   29 |     my_type_t value;
      |     ^~~~~~~~~
      |     idtype_t
/home/erling/dev/lf-ex/src-gen/UseGeneric/include/Generic/Genericmy_type_t.h:43:5: error: ‘my_type_t’ does not name a type; did you mean ‘idtype_t’?
   43 |     my_type_t value;
      |     ^~~~~~~~~
      |     idtype_t
In file included from /home/erling/dev/lf-ex/src-gen/UseGeneric/_genericmy_type_t.cpp:6:
/home/erling/dev/lf-ex/src-gen/UseGeneric/_genericmy_type_t.h:15:5: error: ‘my_type_t’ does not name a type; did you mean ‘idtype_t’?
   15 |     my_type_t value;
      |     ^~~~~~~~~
      |     idtype_t
/home/erling/dev/lf-ex/src-gen/UseGeneric/_genericmy_type_t.h:29:5: error: ‘my_type_t’ does not name a type; did you mean ‘idtype_t’?
   29 |     my_type_t value;
      |     ^~~~~~~~~
      |     idtype_t
/home/erling/dev/lf-ex/src/Generic.lf: In function ‘void _genericmy_type_treaction_function_0(void*)’:
/home/erling/dev/lf-ex/src/Generic.lf:8:10: error: ‘struct _genericmy_type_t_out_t’ has no member named ‘value’
    8 |     out->value = in->value;
      |          ^~~~~
/home/erling/dev/lf-ex/src/Generic.lf:8:22: error: ‘struct _genericmy_type_t_in_t’ has no member named ‘value’
    8 |     out->value = in->value;
      |                      ^~~~~
/home/erling/dev/lf-ex/src-gen/UseGeneric/_genericmy_type_t.cpp: In function ‘_genericmy_type_t_self_t* new__genericmy_type_t()’:
/home/erling/dev/lf-ex/src-gen/UseGeneric/_genericmy_type_t.cpp:10:11: error: ‘my_type_t’ was not declared in this scope; did you mean ‘idtype_t’?
   10 | #define T my_type_t
      |           ^~~~~~~~~
/home/erling/dev/lf-ex/src-gen/UseGeneric/_genericmy_type_t.cpp:47:52: note: in expansion of macro ‘T’
   47 |     self->_lf__in.tmplt.type.element_size = sizeof(T);
      |                                                    ^
make[2]: *** [CMakeFiles/UseGeneric.dir/build.make:104: CMakeFiles/UseGeneric.dir/_genericmy_type_t.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:100: CMakeFiles/UseGeneric.dir/all] Error 2
make: *** [Makefile:136: all] Error 2
lfc: error: CMake failed with error code 2
lfc: fatal error: Aborting due to 1 previous error.

I think the preamble of the file where the generic reactor is instantiated must also be "added" to the preamble of the generic reactor.

[erlingrj]

Any thoughts on this @petervdonovan ?

[petervdonovan]

Hmm, yes, I agree that that should be considered to be a problem. I am not sure what to do about it however. Without interpreting the C header files, the only way to prevent this sort of problem would be for the generic child reactor to be compiled with all the headers of its parent reactor, which seems like namespace pollution which could also lead to large code size (since the child reactor is compiled for every place where it is instantiated, even if the type args are the same). It is possible that we already have these problems anyway for other reasons but I would have to investigate this further to know.