When compiling my Chapel program, I see an error message like:
myProgram.chpl:42: error: use of 'symbol' before encountering its definition, type unknown
but I am unsure what this means or what I should do to resolve it. Can someone help me decipher it?
This error message typically occurs when encountering a circularity while resolving the module-scope variables of a Chapel program.
As a very simple example, consider the following program which defines two modules,
MandN, each of which defines a variable (aandb, respectively):The Chapel compiler will resolve this program as follows:
It starts by trying to resolve
Mbecause it is considered the program's main module due to the fact that it contains themain()procedureIt then sees that
Mdepends onNdue to itsuse Nstatement, so will defer resolvingMuntilNis resolvedIt then sees that
Nalso depends onMdue to itsuse Mstatement, but will note that it's already started to resolveM, so breaks the cycle by ignoring it and continuing to resolveN(similar to a depth-first search on a graph with cycles)It then tries to resolve the type of module-scope variable
bIt sees that
bis initialized usinga, sob's type will depend ona'sHowever, in looking up
a's type, it finds that it doesn't know it yet since the resolution ofMwas deferred untilNwas resolvedThis causes it to print out the error:
Note that while we humans can look at this code and see "Well,
ais clearly an integer, sobshould be an integer as well, what's the problem?", the Chapel compiler's resolution machinery takes a much more constrained approach at present. And arguably this is reasonable because Chapel's definition says thatNwill be initialized beforeMsinceMis the main module and it depends onN. However, that would mean that the program would try to initializebbefore initializingawhich seems counter to the author's intent.That said, the error message could definitely be improved for cases like this to explain more about how the compiler got to the statement in question and help users detangle their inter-module dependencies and orderings.
Please note that having a circular
usechain between modulesMandNis not the inherent source of the problem here, and is an important pattern that's used frequently in Chapel. Such circularities only become problematic when the variable initializations themselves rely on values or expressions that have not yet been resolved using the module resolution/initialization order.Some potential ways to address errors like this include: