chapel-lang/chapel — pull request #44 by lydia-duncan (2014-07-22 20:53:49+00:00)
Title: Do not default initialize return temporary variables, where able.

This commit causes return variables to use noinit instead of default
initialization. The rationale is that these variables will be assigned to
before they are returned, so default initializing them is a waste of time.
It is hoped that more compiler temporary variables can use this in the
future, but there are still some kinks to work out in the meanwhile.

Details of changes:
checkResolved.cpp: The check for if a return variable has been assigned in
all spots had two cases - first, if no assignment occurred; second, if
only default initialization had occurred but the function had specified its
return type. In a world where return temps do not default initialize
themselves except in special cases (see the commit on "pragma ignore
noinit" for specific cases that must still default initialize themselves at
this point in time), we would expect one or more assignments to occur in the
ordinary case instead of at least two. Externs being no longer special in
this regard, it made sense to specify that this second case should only be
triggered if the return type was one of the specified types that cannot use
noinit.

normalize.cpp: For the return temporary variables added here, unless the
function is a param or type function, specify that the variables should not be
default initialized unless necessary. In the case of param or type variables,
using noinit had caused confusion about whether the value returned really was
what the return tag claimed, so we must continue to default initialize them
for now.

functionResolution.cpp: With normalize using noinit for return variables willy-
nilly (as we don't know their type when return temps are inserted), it will
not necessarily be the user's fault when noinit is applied to a type that
can't use it. This squashes that warning ("type does not currently
support noinit") in the case where the variable is a return temp and thus not
the user's fault.