Custom Query (145 matches)

So polymorphic types can lead to an assertion failure if there is a reference to a reference to a forward declared polymorphic type where the type parameter is a dtype.

Here is the error message:

*CFA assertion error* "baseParam == baseParams.end() && param == params.end()" from program "cfa-cpp" in "GenPoly::genericType GenPoly::makeSubstitutions(const std::__cxx11::list<TypeDecl*>&, const std::__cxx11::list<Expression*>&, std::__cxx11::list<TypeExpr*>&)" at line 268 in file "GenPoly/InstantiateGeneric.cc": Type parameters should match type variables

Here are two different ways to reproduce the error, both are pretty minimal:

forall(dtype T)
struct link;

forall(dtype T)
struct link {
    link(T) * next;
};

forall(dtype T)
struct foo;

forall(dtype U)
struct bar {
    foo(U) * data;
};

forall(dtype T)
struct foo {};

Changing the first dtype in either example to an otype will cause them to compile successfully. You can also reorder the declarations to fix them and changing the other polymorphic variable declarations doesn't change anything with most combinations.

So I have encountered a rather convoluted case where a combination of a circular dependency and a polymorphic function pointer leads to an error in the generated code. It appears that a concrete implementation is not getting forward declared.

bug.cfa:12:72: warning: 'struct _conc_object0' declared inside parameter list will not be visible outside of this definition or declaration
   12 |  void (*object_function)(object(T) *);
      |

Here is the code to produce the error (the _vtable names are from how I discovered this but are not required, the virtual system seems to have nothing to do with this):

forall(otype T)
struct object_vtable;

forall(otype U)
struct object {
    object_vtable(U) * virtual_table;
};

forall(otype T)
struct object_vtable {
    void (*object_function)(object(T) *);
};

void func(object(int) * test) {}

object_vtable(int) _object_vtable_instance = { func };

The polymorphic variables currently have to be otypes because of #196. Once that bug is fixed they might be able to be changed to dtypes.

In object removing the virtual_table pointer or replacing it with a field that does not refer to object_vtable will cause the error to disappear. Whether the field is polymorphic or not doesn't matter, object_vtable(char) * produces the error but U * does not.

In object_vtable the function pointer field must refer to object and must be a function pointer. So the error remains with void (*f)(object(int) *) as long as the structure is polymorphic. But object(U) * x will compile just fine as will void (*f)(U *).

Also if the star is removed from the function pointer argument (and the same star on func) there is a burst of possibly related errors. If the initialization at the end of the examples is also changed this becomes a single warning on assignment of incompatible pointer types. Not sure if that is the same problem or not.

The initialization of _object_vtable_instance is required for the error to occur. It also happens if you use @= to initial the structure, it leads to an extra error:

bug.cfa:19:82: warning: initialization of 'void (*)(struct _conc_object0 *)' from incompatible pointer type 'void (*)(struct _conc_object0 *)' [-Wincompatible-pointer-types]
   19 | object_vtable(int) _object_vtable_instance @= { func };
      |
             
bug.cfa:19:82: note: (near initialization for '_X23_object_vtable_instanceS13object_vtable_i__1._X15object_functionFv_PS6object_Y12__T_generic____1')

Currently we remove all attributes from typedef uses when they are put into a function type. There appears to be an explicate filter that removes them in the ReplaceTypedef? pass. However some attributes actually need to be copied over - even if some of them must not which is probably why they were removed in the first place.

A better solution is just to remove the ones that cannot be copied over. The default probably should be to copy them over as that seems like it will be the solution more often and so far extra attributes have raised much more noticeable errors then missing attributes.

So far aligned appears to be the only one that should be removed.