Recent update broke structs in structs in autowrap test

[atilaneves]

I can't use pyd 0.9.9 given the fixes that have gone in since then, which leaves me with using pyd master. Unfortunately, that means that the current master branch has broken functionality by making autowrap's tests fail. I used git bisect and this is the commit that introduced the regression:

commit fe4b61ab6313f14b5d7b57fae16fbb95d9a75fa5
Author: Ellery Newcomer <ellery-newcomer@utulsa.edu>
Date:   Fri Aug 31 20:16:03 2018 -0700

    support structs in structs

    also, dmd 2.067.1 doesn't seem to want to work in debian 9

i.e. this commit.

The code that failed to be wrapped was this:

export auto createOuter(double x, double y, double value, string string1, string string2) {
    import templates;
    import structs: String;
    return Outer!double([
                            Inner1!double(Point!double(x, y), value),
                            Inner1!double(Point!double(x, y), value + 1),
                        ],
                        Inner2!double(EvenInner!double(value)),
                        String(string1),
                        String(string2));
}

struct Point(T) {
    T x, y;
}

struct Outer(T) {
    import structs: String;
    Inner1!T[] inner1s;
    Inner2!T inner2;
    String string1;
    String string2;
}

struct Inner1(T) {
    Point!T point;
    T value;
}

struct Inner2(T) {
    EvenInner!T evenInner;
}

struct EvenInner(T) {
    T value;
}

After calling createOuter, it's impossible to access the Point structure inside an inner:

o = create_outer(2.0, 3.0, 33.3, "foo", "bar")
[fst_i1, snd_i1] = o.inner1s
fst_i1.point.x

AttributeError: 'simple.Inner1' object has no attribute 'x'

This is odd, since while it's true that Inner1 has no x member, Point does. So:

>>> type(fst_i1)
<class 'simple.Inner1'>

So far, so good.

>>> type(fst_i1.point)
<class 'simple.Inner1'>

Which is obviously wrong. Again, this problem starts with the commit referenced above.

[ariovistus]

sounds kind of like a bug I'm aware of (and the last unit test in referenced commit details it) where the python type is sometimes wrong. I have no idea what is causing it, but I don't think it's a logic error. If you read the type out of the PyObject* it will return the right type. I'll look at it again tonight

[ariovistus]

dang it, it is a logic error

[ariovistus]

try master now

[atilaneves]

It works now, thanks.