adding ckCheck to ckLocal control flow

[mayantaylor]

Addressing issue #3775.

OVERVIEW

Operating on an uninitialized array proxy should consistently abort with "Error! This array proxy has not been initialized!" Other error messages, like "Group ID is zero-- invalid!", while signifying the same issue, introduce inconsistencies and are less clear to the user. Inserting 'ckCheck' into the CkLocal control flow handles the initialization issue earlier and prints consistent error messages, but results in duplicate code and might not be the best solution to this problem.

ISSUE DETAILS

Note that the following examples assume a non-production charm++ build.

Firstly, consider the following two lines of code on some chare array Elements with entry method calculate:

CProxy_Elements elements;
elements[0].calculate();

This fails as expected:

CHARM++ FATAL ERROR: Error! This array proxy has not been initialized!

This error is thrown by CProxy_ArrayBase::ckCheck(). From what I can tell, ckCheck() is inserted at the beginning of the proxy implementation of any entry method (in the generated .def.h) before sending the message to the corresponding chare. ckCheck() ensures an array proxy has been initialized by checking that the groupID is non zero.

All classes that inherit from CProxy (CProxy_Chare, CProxy_Group, CProxy_ArrayBase, CProxy_NodeGroup) implement a version of ckCheck(), essentially all checking the same thing (groupID != 0) and aborting with slightly different error messages if necessary, to specify what type of proxy hasn't been initialized. CProxy is not an abstract superclass and doesn't require an implementation of ckCheck though.

Now, consider the following contrived example:

CProxy_Elements elements;
elements[0].ckLocal();

Which aborts with:

Group ID is zero-- invalid!

If CkLocal() is called on an uninitialized proxy, the groupID is not checked until the call to GroupIdxArray::find(CkGroupID), at which point the program no longer has context for what type of proxy we are dealing with and therefore cannot print a more descriptive error message.

A POTENTIAL SOLUTION

Inserting a call to ckCheck along the CkLocal pipeline just before control flow loses reference to what type of proxy is being handled enables the runtime to print the expected error message (this is what I've implemented). However, with this change, ckCheck will often be executed redundantly: in the case of a simple entry method invocation on an array proxy, ckCheck will be called from within the .def.h proxy implementation of the entry method and then again within CkLocal, which is invoked by ckSend() to send the message to the chare.

I'm not sure about the best way to insert this check into the general logic of the charm++. Is it necessary to run ckCheck immediately on any entry method invocation, or is there a way to embed it a little deeper so that issues like that tagged don't reoccur?