|
To make sense of this, I see two problems here: 1. In the above testcase, the first line is parsed as an assignment rather than a field declaration and, perhaps consequently, the recursive method definition is parsed as a DeclarationStatement rather than a Method. 2. Methods nested in other methods are transformed into closures inside their parent method, and as a result, they cannot be recursive since they are not part of their own display class. As a result of these, both members in the above testcase (the "global field" and the "method declaration") are considered global statements rather than module members, and are thus left inside the generated Main() method as part of the IntroduceModuleClasses step. This makes the recursive method a nested method inside Main(), and consequently it fails to invoke itself. We can fix either of the two problems: 1. We can make sure that method definitions inside a module are parsed as methods regardless of where they appear. 2. We can allow nested methods to call themselves (and other nested methods under the same parent method) by considering method invocations, in addition to references, when computing a closure's display class. Which (or both) do you think is right? Resolved in r3050 by allowing nested functions to recursively call themselves. The fact that the testcase is being incorrectly parsed should still be examined, though. |
|||||||||||||||||||||||||||||||||||||||||
I can confirm this as of r3043. If the whole thing is put into a class, everything works.
Minimal testcase:
>>> BCE0005: Unknown identifier: 'recursive'.