chapel-lang/chapel — pull request #953 by hildeth (2014-12-03 00:25:42+00:00)
Title: Fix return-record bug.

The problem was partly genuine bugs and partly pilot error.

Pilot error: The Zed class in the test needs to supply a chpl__initCopy()
function that handles memory correctly. I supplied one.

Bug 1: Missing initialization of return value variable: Initialization of the return value
variable was changed to PRIM_NO_INIT in commit 45ac0d. This is not correct. The
initialization is needed for MM. (Works fine with scalar types, blows up types that
perform their own MM).

After the return value type is computed statically (even when declared) and the
establishment of the return value always uses copy-construction, then this initialization
can be removed. Until then, we need to preserve it.

Bug 2: Autodestroy of return value variable when its type is declared: We probably just
never tested for this specific case.

##DETAILS

###compiler/passes/normalize.cpp
Restored the code to always initialize the return value variable. This will probably
result in a performance degradation. Any performance gain in the interim is specious;
however, moving to establishing the return value only once through initialization will
restore the performance gain "correctly".

###compiler/resolution/callDestructors.cpp
In cullAutoDestroyFlags(), if the return value is specified, also remove the autodestroy
flag. In this case, ownership of the return value is passed to the caller. (The other
case -- where the return type is not specified -- should probably do the same thing.)

###modules/standard/Types.chpl
Calls to PRIM_INIT added in normalize.cpp now call _defaultOf(). When there is a return
value variable of type "void" it calls _defaultOf(void). This was declared as a param
function, but since it returns a value that has a runtime representation, postFold
complains that it is not a param function. Solution: Removed the param keyword.

This is a workaround. It would be better to prevent the creation of a "void" return value
variable in the first place. This will probably just fall out of reworking return type
resolution so it does not depend on their being a return value variable....