floor division on ctypedef-ed type results in non-compilable C code

[robertwb]

This seems like a regression w. respect to 0.11.3.

Basically,

ctypedef Py_ssize_t index_t

def m_range_lm(index_t lmax):
    cdef index_t numcoefs = lmax // 2

results in

compiling (c) and running numpy_dagss ... numpy_dagss.c:296: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__Pyx_div___pyx_t_11numpy_dagss_index_t'
numpy_dagss.c: In function '__pyx_pf_11numpy_dagss_m_range_lm':
numpy_dagss.c:372: warning: implicit declaration of function '__Pyx_div___pyx_t_11numpy_dagss_index_t'
numpy_dagss.c: At top level:
numpy_dagss.c:511: error: conflicting types for '__Pyx_div___pyx_t_11numpy_dagss_index_t'
numpy_dagss.c:372: error: previous implicit declaration of '__Pyx_div___pyx_t_11numpy_dagss_index_t' was here

Migrated from http://trac.cython.org/ticket/384

[robertwb]

@dagss changed owner from somebody to dagss
status from new to assigned
commented

[robertwb]

@dagss commented

I'm deep into the issue behind this ticket, but a fix proves difficult for the case of

complex_arithmatic_utility_code

which can both depend on user-defined types and provide new ones. Luckily it cannot generate/get any type, so a code block order of

typedefs
utility code emitting complex types
utility code requiring use of complex type

should suffice. Would rather avoid making a full graph of code block dependencies, but can do that too. Will get back to it tomorrow or so.

[robertwb]

@dagss changed resolution to fixed
status from assigned to closed
commented

http://hg.cython.org/cython-unstable/rev/09b4a8a9798b

But see http://trac.cython.org/ticket/386.