[Cython] Bug in Cython producing incorrect C code

[Stefan Behnel]

mark florisson, 26.01.2012 16:20:
> On 26 January 2012 06:39, Vitja Makarov wrote:
>> 2012/1/25 Stefan Behnel:
>>> Back to the old idea of separating the type analysis into 1) a basic
>>> typing, inference and entry creation step and 2) a proper type analysis,
>>> coercion, etc. step.
>>>
>>
>> Yeah! I think the issue must be fixed before release. We can start
>> moving slowly in this direction and split
>> CascadedAssignmentNode.analyse_types into parts:
>>  - normal analyse_types()/expressions()
>>  - create clone nodes at some late stage
> 
> At what stage would the stage 2) proper type analysis take place?

After the structural optimisation phase and before any optimisations or
other transforms that require complete type information but do not change
types anymore. I don't see it being moved to the end of the pipeline, the
results will be needed way before that. Even some optimisations may not be
possible without complete type analysis.


> Basically nodes may be replaced at any point, and I'm not sure you
> want to wait until just before code generation to do the coercions
> (e.g.  GILCheck won't catch coercions to object, although assignment
> nodes seem to check manually).

There's a large grey area in between. It'll need some refactoring and
rebalancing, just as before. But it should be easier than it is now because
the grey area will have more anchors in it.


> I think this problem can trivially be solved by creating a ProxyNode
> that should never be replaced by any transform, but it's argument may
> be replaced. So you wrap self.rhs in a ProxyNode and use that to
> create your CloneNodes.

I can't see what a ProxyNode would do that a CloneNode shouldn't do anyway.

Stefan