On Mar 18, 2009, at 10:59 AM, Dag Sverre Seljebotn wrote: > Stefan Behnel wrote: >> Hi, >> >> Kurt Smith wrote: >>> Ticket 135 (return statement outside a function body crashes cython) >>> can be fixed with a simple assignment of None to self.return_type in >>> the Scope __init__ function. The crash happens when there is a >>> return >>> statement in the class body as well as at the module level. >>> >>> Every function object explicitly assigns something else to the >>> scope's >>> return_type, so the function objects are not affected by this >>> change. >>> >>> Here's the diff with a test case included. I included this on the >>> trac page, but thought it would be easiest to get it pushed here. >>> >>> diff -r e2365a6d00b8 -r f153d2da27b0 Cython/Compiler/Symtab.py >>> --- a/Cython/Compiler/Symtab.py Tue Mar 17 07:32:51 2009 +0100 >>> +++ b/Cython/Compiler/Symtab.py Tue Mar 17 15:10:14 2009 -0500 >>> @@ -235,6 +235,7 @@ class Scope(object): >>> self.pystring_entries = [] >>> self.buffer_entries = [] >>> self.control_flow = ControlFlow.LinearControlFlow() >>> + self.return_type = None >>> >>> def start_branching(self, pos): >>> self.control_flow = self.control_flow.start_branch(pos) >> >> Thanks for looking into this. Without actually knowing the >> details, I'm not >> sure yet that this is a good way to do it. I do not have high >> confidence in >> the current handling of the return_type, so setting it globally in >> a class >> might cover incorrect assumptions in other parts of the code that >> just >> expect that the return_type is set at some point in the pipeline >> where it >> normally wouldn't be set (i.e. long before code generation). I ran >> into >> tons of problems like these since I started working on ticket 144. >> It's >> actually possible that this will be fixed when I'm done with that >> ticket. > > If not, PostParse (in ParseTreeTransforms.py) is a very safe spot > to do > things like this. One can trivially implement visit_ReturnStatNode and > raise syntax errors if one is not within a function, and it means that > if there's an error, one simply stops before getting to somewhere > it can > cause trouble. > > IMO more error checking (e.g. for most syntax errors) should go > into there.
+1 to this idea. It's a lot clearer what's going on. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
