Re: [Swig-devel] typedef resolution

[Marcelo M. <mm...@ac...>]

Well, I took a look, the difference in treesTesO in enum_thorough seems 
to be doing the
same as in 1.3.28 and 1.3.27.

With arrays.i we are getting a different type due to this change in stype.c:

    /* Resolve any typedef definitions */
 -   td = SwigType_typedef_resolve(tc);
 +    td = SwigType_typedef_resolve_all (tc);
    if (td && (SwigType_isconst(td) || SwigType_isarray(td) || 
SwigType_isreference(td))) {
      Delete(tc);
      tc = td;
    } else if (td) {
      Delete(td);
    }

this was necessary since the plain SwigType_typedef_resolve resolve the 
typedef just once
in the scope, which is then inconsisten since you can have a typedef out 
of the scope
or concatenated typedefs. At the end, that inconsistence make this case 
to fail (array_members.i):

typedef char SBUFF[BUFF_LEN];
typedef SBUFF MY_SBUFF;
typedef struct _sm {
  int i;
  MY_SBUFF x;
} MySBuff;

with something like

array_member_wrap.cxx: In function `PyObject* 
_wrap_MyBuff_x_set(PyObject*, PyObject*)':
array_member_wrap.cxx:3609: error: incompatible types in assignment of 
`unsigned char*' to `unsigned char[12]'
array_member_wrap.cxx:3639: error: ISO C++ forbids casting to an array 
type `unsigned char[12]'

but this worked (one typedef  'chain')

typedef char SBUFF[BUFF_LEN];
typedef struct _sm {
  int i;
  SBUFF x;
} MySBuff;

since the type reduction was performed.

And as you, in the stype.c code, the typedef reduction is only used in the
case of (SwigType_isconst(td) || SwigType_isarray(td) || 
SwigType_isreference(td))
which requires special handling in cwrap, independent of one or more 
concatenated
typedefs involved.

In short, the fix "fixed" a previous typedef issue that was partially 
solving just
the 'one typedef' case, but fails in the general case of multiple 
concatenated typedefs.

If the previous code was working for arrays/reference/const types
and the one typedef case, where the type reduction was performed,
I think the new code will have the same chances to work when
resolving multiple typedefs.

But if you know a particular compiler case that is not working
for the arrays + typedefs case, we will need to take another look.

At least now we have a case that shows that the patch is neccessary.


I'll take a look at the STL case, which example is in particular?

Marcelo



William S Fulton wrote:

> Marcelo Matus wrote:
>
>> William S Fulton wrote:
>>
>>> I notice that some typedefs are being expanded again, for example, 
>>> treesTestO in enum_thorough.i and FLOAT in arrays.i and value_type 
>>> in the STL. Can we have them back to how they were as we've had 
>>> problems with some compilers requiring the cast to be the typedef'd 
>>> type and not the fully resolved type? Ie the type passed in to a 
>>> method must be cast exactly as declared in the function.
>>
>>
>> did you notice this  with 1.3.29 or with 1.3.28?
>
>
> It happened after the 1.3.28 release.
>
> William