On Mar 23, 2009, at 10:44 AM, Kurt Smith wrote: > On Wed, Mar 18, 2009 at 12:59 PM, Dag Sverre Seljebotn > <[email protected]> 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. >>>> > [snip] >>> >>> 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. > > Would it be worthwhile to pursue a fix for #135 by modifying code in > the PostParse phase as Dag mentions here, or is the fix going to be > subsumed by 'fixing' ticket #144? > > If the former, I'll take a stab at it.
I think it's worth doing the former, in place of the current patch up at #135. I would say the current patch covers up bad code, while modifying PostParse will avoid it (which is both cleaner and leads to less potential confusion/unintended effects later). - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
