Custom Query (145 matches)

This code creates a warning and shouldn't :

int foo(int) { return 3; }

Rob left some comments on the design of the TupleType AST node suggesting some different design directions (see src/SynTree/TupleType.cc or src/AST/Type.cpp). The gist is that the relationship between the types and members fields is non-trivial, and could be factored out more cleanly.

Comment verbatim below:

This is very awkward. TupleType should contain objects so that members can be named, but if they don't have an initializer node then they end up getting constructors, which end up being inserted causing problems. This happens because the object decls have to be visited so that their types are kept in sync with the types list here. Ultimately, the types list here should be eliminated and perhaps replaced with a list-view of the object types list, but I digress. The temporary solution here is to make a ListInit with maybeConstructed = false, that way even when the object is visited, it is never constructed. Ultimately, a better solution might be either:

a) to separate TupleType from its declarations, into TupleDecl and Tuple{Inst?}Type, ala StructDecl and StructInstType

b) separate initializer nodes better, e.g. add a MaybeConstructed node that is replaced by genInit, rather than what currently exists in a bool

The following code fragment causes inifinite recursion in member TypeSubstitution::Substituter::postmutate.

forall( dtype ostype ) {
    ostype & ?|?( ostype &, ostype & (*)( ostype & ) );
    ostype & nonl( ostype & );
    ostype & ?|?( ostype & os, int ) {
	os | nonl;
    }
}