Custom Query (145 matches)

In the following code:

forall(T&)
struct A {
    T * next;
};

struct B {
    A(B) link;
};

void baz() {
    for(B ** it;;it = &(*it)->link.next) {}
}

The for loop is codegened as:

void _X3bazFv___1(){
    {
        struct B **_X2itPPS1B_3;
        struct B **_dtype_static_member_245 = ((struct B **)(&(*(*_X2itPPS1B_3))._X4linkS1A_S1B__1._X4nextPY12__T_generic__1));
        for (;;((void)(_X2itPPS1B_3=_dtype_static_member_245))) {
        }
    }
}

This moves the loop increment outside the actual loop, which causes infinite loops.

The problem is probably either in Instantiate Generic pass or in the Pass visitor.

Instantiate Generic is the pass creating the variable _dtype_static_member_245, searching from src/GenPoly/InstantiateGenericNew.cpp:384 (as of time of writing) should yield the namer.

It could also be because the pass visitor needs to handle stmts_to_add better in this case.

C supports structures with "flexible array member", i.e.,

struct SomeStruct {
	int NormalFields;
	char FlexibleArray[];
};

These structures do not really have a known size and therefore we shouldn't be automatically generating assignment operators or field constructors.

I can see this being handled in a few ways:

• Going through all the members in FuncGenerator::genStandardFuncs.
• Mark the struct as special earlier than that.
• Have the resolver somehow mark these as unresolvable.

These autogenerated functions cause the following output: "note: the ABI of passing struct with a flexible array member has changed in GCC 4.4"

For whatever reason, statements seem to have some cases where a child node is needed but it isn't its own statement. This problem has either been solved by making them their own statement anyways (such as the FinallyStmt?) or by packing a lot of data structures into one node (such as the WaitForStmt?).

The first solution (pretend it is a statement) does work as long as there are no mistakes confusing this node for a statement and none of the special machinery around statements is activated. There are also some speed and memory advantages but they are very small.

The second solution (make it all one node) requires a lot more manual work and introduces more special cases. A lot of that has already been done but new cases keep coming up.

The new solution is to add a new super node to Stmt.hpp:

// Represents a significant section of a statement.
class Clause : public ParseNode {
  public:
    Clause( const CodeLocation & loc ) : ParseNode(loc) {}

    Clause( const Clause & o ) : ParseNode( o ) {}

    const Clause * accept( Visitor & v ) const override = 0;
  private:
    Clause * clone() const override = 0;
    MUTATE_FRIEND
};

All the new "Clause" types inherit from this node and could be given a new suffix. It inherits from ParseNode? so get a code location for debugging and error messages. Also the child clauses could inherit directly from ParseNode? but this helps with organization.

A similar solution could be used with expressions/Expr and declarations/Decl, but it just hasn't come up and even if it did there is less special cases around Expr and Decl as compared to Stmt, so the improvements would be fewer.

(This might be pushed back to after the old AST is removed to that maintaining symmetry between the new and old AST is not a factor in the rework.)