Vitja Makarov, 27.01.2011 10:49: >>>>>>>>>> def x(): >>>>>>>>>> do_some_stuff() >>>>>>>>>> >>>>>>>>>> return # disable rest of code, e.g. during debugging >>>>>>>>>> >>>>>>>>>> unreachable_code() >>>>>>>>>> >>>>>>>>>> Cython shouldn't bother generating dead code here (even if the C >>>>>>>>>> compiler >>>>>>>>>> would drop it anyway). >>>>>>>>> >>>>>>>>> That should be rather easy to do: remove all the nodes in StatList >>>>>>>>> after: break, continue, return, raise, something else? >>>>>>>> >>>>>>>> Careful, this may involve recursive propagation through helper nodes. >>>>>>>> The >>>>>>>> tree isn't always as simple as that. >>>>>>>> >>>>>>>> I think an attribute "is_terminator" on Nodes might do the job. >>>> the StatListNode (and >>>> other nodes) should inherit the flag from their last child. >> >>> I don't actually understand where could be that used later? >> >> Well, if you recursively propagate the flag through nodes that support it, >> you may end up in another StatListNode that strip its trailing dead code. >> Look through UtilNodes.py, there are a couple of nodes that can wrap >> Stat(List)Nodes. Maybe check Nodes.py also, not sure if there aren't any >> other nodes that can safely assume that a terminator at the end of their >> last child makes them a terminator as well. > > return and loop-controls are very different here > > if cond: > return 1 > else: > return 0 > # dead code follows > > We can set is_terminator here if all the clauses are terminators > > for i in a: > if i> 0: > continue > else > break > # dead code here > > for i in a: > return > # not dead > > for i in a: > return > else: > return > # dead > > It seems to me that each case should be handled its own way. > We can't simply say: this node have child with is_terminator set so > it's terminator too.
That's what I meant, yes. You may also consider making is_terminator a method instead of a simple attribute. That would allow nodes to reimplement it (even recursively) and make decisions based on their context. > Is there a way to write tests for warnings? If no think we should create one. Not yet, it wasn't really a high priority back when I wrote the error test support. >>>>> Some error tests do fail because nodes are removed and code generation >>>>> time error is omited. >>>> >>>> That should be fixable in most cases. We could also use a compiler option >>>> that disables dead code removal, and then use it in the error tests. >>> >>> Hmm, not sure here. >>> I think it should be better to move checks outside code generation. >> >> Ah, ok, I misunderstood you then. Yes, errors should no longer occur at >> code generation time. > > Think that's whole lot of work. Steps in that direction have been taken several times already. Hopefully, they will eventually converge to the expected state. > When implementing generators I've moved error checking into > ParseTreeTransforms > and left 'yield not supported' in YieldExprNode. That could be later > replaced with: raise InternalError Hmm? YieldExprNode is used and generates code, doesn't it? Or did you mean to raise InternalError on errors that should have been caught before? I don't think there's a need to retest inside of the node. If someone disables that transform, I'm fine with seeing Cython crash. Stefan _______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
