Commit 6460e490 authored by Matthew Johnson's avatar Matthew Johnson

Add MemoryViewSliceType.specialization_name() to include dtype in name

Calling inherited BaseType.specialization_name() on a
MemoryViewSliceType generates a name like "Pyx_memviewslice", which
meant, for example, that generated utility code could have a name like

    __pyx_convert_from_py__Pyx_memviewslice

which would collide with utility code generated for other memoryviews
that might have other base types. That would mean something like

    def test_memviews_diff(a,b):
        cdef vector[double[:]] aa = a
        cdef vector[int[:]] bb = b

would first have a compile error (function redefinition due to how
utility code is currently generated) and second, if only one such
utility function were emitted instead of one for each memoryview base
type, have problems with any type-specific generated code, e.g.

    // generated inside __Pyx_PyObject_to_MemoryviewSlice,
    // which is called from __pyx_convert_vector_from_py___Pyx_memviewslice
    // note __Pyx_TypeInfo_double
    retcode = __Pyx_ValidateAndInit_memviewslice(axes_specs, 0,
                                                 PyBUF_RECORDS, 1,
                                                 &__Pyx_TypeInfo_double, stack,
                                                 &result, obj);

By adding the dtype tag to the name string returned by
specialization_name(), distinct utility code functions are generated (at
least in the case above) and thus there is no name collision.
parent db4001fa
......@@ -670,6 +670,10 @@ class MemoryViewSliceType(PyrexType):
return True
def specialization_name(self):
return super(MemoryViewSliceType,self).specialization_name() \
+ '_' + self.specialization_suffix()
def specialization_suffix(self):
return "%s_%s" % (self.axes_to_name(), self.dtype_name)
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment