Separated the problematic code, add the following to bridging header and do UnsafeMutablePointer<Foo>.alloc(1) somewhere in Swift.

typedef struct Foo {
    int x;

    enum {
        A = 0, B, C
    } y;

    int z;
} Foo;

This is solidly reproducible when nested enum is surrounded with primitive properties, I've tried int and char. Frankly, when the enum is surrounded with structs the compiler doesn't crash:

typedef struct Bar {
} Bar;

typedef struct Foo {
    struct Bar *x;

    enum {
        A = 0, B, C
    } y;

    struct Bar *z;
} Foo;

When the enum is the last element in the structure the compiler also doesn't crash:

typedef struct Foo {
    int x;

    enum {
        A = 0, B, C
    } y;
} Foo;

Fun times!

Interesting. Thanks for the reduction!

Comment by Ronak Patel (JIRA)

I just ran into this issue with Xcode 9.1; and ffmpeg 3.4. Any word on when this would be fixed?

@swift-ci create

Arnold tracked this one down to us importing the anonymous enum as having an underlying type of Int rather than Int32. We could fix just the storage part, but then you wouldn't be able to write foo.y = A. On the other hand, changing the type of the constants would break existing source. Still, we should do something here.

If you're willing to hack the headers as a workaround, you can either give the enum a name or an explicit underlying type, enum : int, as supported by Objective-C and C++11. If you're worried about breaking C code (reasonable), you can guard it with #if defined(__swift__).

#13984

Fixed in master (but unfortunately not the 4.1 branch, since we're trying to be less disruptive there).

Comment by Ronak Patel (JIRA)

Which version of Xcode would have this fix?

Whichever one gets Swift 5. (Apple policy won't let me say more than that.)

Update: "whichever one gets Swift 4.2, which hadn't been invented at the time"