• Matthew Johnson's avatar
    Add MemoryViewSliceType.specialization_name() to include dtype in name · 6460e490
    Matthew Johnson authored
    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.
    6460e490
PyrexTypes.py 150 KB