Well... this just fixes the symptom, not the root cause.
I really would like to know where the stack overflow occurs, but I was not able to find it.
Debugging boo code with DebugCLR does not seem to work very well...
I don't exactly know what ProcessMethodBodies does.
Does it need type information about the types operating on? BooBinding does not load referenced libraries/projects; it is using the information provided by SharpDevelop. And that is loaded directly from the assembly (using ICSharpCode.SharpAssembly, not System.Reflection) and is not available to the compiler steps.
So what seems to work with BCL types could fail with types from custom assemblies.
That's why BooBinding does most resolving on its own, not reusing the methods from the boo compiler.
I have implemented my own methods to infer the return type using the information available from SharpDevelop. (believe me I checked that code for possibilities of infinite recursion; I just can't find the place where the stack overflow it is happening!)
If ProcessMethodBodiesWithDuckTyping works even when the information from the referenced assemblies is not available, this patch can be applied because ProcessMethodBodiesWithDuckTyping will do a much better job than my code.