[Cython] Control flow graph

[Vitja Makarov]

2011/2/16 Vitja Makarov <vitja.makarov at gmail.com>:
> 2011/2/15 Stefan Behnel <stefan_ml at behnel.de>:
>> Robert Bradshaw, 15.02.2011 08:21:
>>>
>>> On Mon, Feb 14, 2011 at 9:49 PM, Vitja Makarov wrote:
>>>>
>>>> 2011/2/15 Robert Bradshaw:
>>>>>
>>>>> On Sun, Feb 13, 2011 at 11:40 PM, Vitja Makarov wrote:
>>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> In order to implement "reaching definitions" algorithm.
>>>>>> I'm now working on control-flow (or data-flow) graph.
>>>>>>
>>>>>> Here is funny picture made with graphviz ;)
>>>>>>
>>>>>> http://piccy.info/view3/1099337/ca29d7054d09bd0503cefa25f5f49420/1200/
>>>>>
>>>>> Cool. Any plans on handling exceptions?
>>>>
>>>> Sure, but I don't have much time for this :(
>>>>
>>>> Linear block inside try...except body should be split by assignments
>>>> and each subblock should point to exception handling entry point.
>>>
>>> Would every possible failing sub-expression have to point to the
>>> exception handling point(s)?
>>
>> Well, in most cases (especially the interesting ones), this will be the
>> function exit point, so it'll be easy. And in some cases, we may be able to
>> infer that a specific exception that an expression (e.g. arithmetics or a
>> 'raise' statement) can raise will not get caught by a given except clause
>> (although that's certainly a tricky optimisation).
>>
>> But in general, I think any subexpression that potentially raises an
>> exception must point to the next exception handling point.
>>
>>
>>> I suppose it depends on whether you'll be handling more than assignment
>>> tracking.
>>
>> We *may* get away with a statement-level graph in that case, but I somehow
>> doubt it already. For example, list comprehensions leak their variable in
>> Py2 code, so it's important to know if they are executed or not, and they
>> may appear in any kind of expression.
>>
>
> Hmm... both python and codespeaks in the thread
>
> Here is my commit it's mostly broken now but anyway
> https://github.com/vitek/cython/commit/5579b23c3c1c06981331b6427a73e5cb19980b8a
>
>

I've update stuff:
 - algo for finding definitions
 - warnings for uninitialized and may be uninitialised use
 - few test cases

Trying to compile ParseTreeTransforms.py I've found this for example:

warning: Cython/Compiler/ParseTreeTransforms.py:1182:27: Variable
'template' may be used uninitialized

    def create_Property(self, entry):
        if entry.visibility == 'public':
            if entry.type.is_pyobject:
                template = self.basic_pyobject_property
            else:
                template = self.basic_property
        elif entry.visibility == 'readonly':
            template = self.basic_property_ro
        property = template.substitute({
                u"ATTR": ExprNodes.AttributeNode(pos=entry.pos,

obj=ExprNodes.NameNode(pos=entry.pos, name="self"),
                                                 attribute=entry.name),
            }, pos=entry.pos).stats[0]



-- 
vitja.