Problem with multiple return values about cone HOT 4 CLOSED

When debugging the compiler errors out in function
void returnTypeCheck(TypeCheckState *tstate, BreakRetNode *retnode)
in ir\stmt\return.c:

Specifically line 61:
if (fnsig->rettype->tag == TTupleTag) {
if (retnode->exp->tag != VTupleTag) {
errorMsgNode(retnode->exp, ErrorBadTerm, "Not enough return values");
return;
}
...

I don't understand enough of the compiler, but this function is called quite a number of times until:

TTupletag is 32777
fnsig->rettype->tag is 32777
VTupleTag is 16392
retnode->exp->tag is 16409
so the errorMsgNode(retnode->exp, ErrorBadTerm, "Not enough return values")
is returned.

I would like to be able to see where it goes wrong, but for the moment allthough I can see the contents of variables like tstate and retnode, I can't figure out what for example 32777 means. Let alone to see where something possibly goes wrong earlier for this case.

from cone.

A node's tag field identifies exactly what kind of AST/IR node we are working with. There are dozens, and all of them are enumerated in the inode.h include file. TTupleTag means we have a tuple type (e.g., 'f32, Bool'). VTuple means we have a tuple value (e.g., '0f, false').

In the diagnostic information you looked at (great job), you discovered that the return signature expected a tuple type, and that the type of the 'if' expression was also a tuple type. Great! It then checked to see if the returned expression node was a tuple value, and it wasn't. If we look at the tag number you found, it corresponds to an 'if' node.

Looking at the code, this makes sense, the implicit return statement wraps around the 'if' statement. If we do a return on a vtuple, we won't get this error (everything works). But the return typecheck logic does not know how to handle a return on an 'if' expression, all of whose path blocks ending with a vtuple.

After taking a brief look at the return typecheck logic, I can see it is too narrow. It should not be expecting the expression to be a vtuple, so lines 62-65 likely don't belong. But once we remove them, we are going to have further problems, beginning with line 66 which expects that the return expression is a VTupleNode (and now we know it might not be). So, this line is not okay and needs to be struck, but then how do we handle the follow-on logic that uses retnodes?

• Line 68 is easy to fix. Instead of looking at the number of values in the expression, we should use the expression's type (which is a tuple type) to compare that the two types (fnsig, and exp->vtype) have exactly the same number of elements.

• Line 74 etc is harder to fix, because of the value coercion in line 76. Coercing individual values in a tuple is nice, but not always possible. It can be done for a vtuple expression, but not so well for other nodes. So, my near-term suggestion is to duplicate the logic in lines 75-78, conditional on whether the expression is a vtuple. When it is a vtuple, do what it does there. When it is not a vtuple (e.g., if), don't do coercion, change the logic to do type equivalence match using the expression's type.

Let me know if the above makes sense or not, and how you would like to go forward from here. There is no rush on this bug, so if you want to wrestle with it as a learning experience, I am happy to walk that journey with you. If you want me to make the fix which you can then study, that too is fine. Whatever aligns best with your goals and time!

from cone.

@Ivo-Balbaert , you indicated you are stuck on my comment about line 68. You are right that Intellisense is likely of limited help here, but I do not know where you are stuck on this.

I re-examined my advice and realized it was headed the right way, but was flawed. It turns out the fix is much simpler, and I went ahead and made it just by changing a few lines. It ended up doing the above in a much simpler way.

Happy to explain anything that is unclear after you have had a chance to look at it!

from cone.

Thanks!

from cone.