1

Hi! I've stumbled upon Swift generated interface behavior that I don't understand, and I would appreciate any insights on this.

Let's say there's a couple of modules declared in a modulemap file like this:

module A {
    header "a.h"
    export *
}
module A2 {
    header "a2.h"
    export *
}

// a.h
typedef int MyInt;
MyInt a() { /* ... */ }

// a2.h
#include "a.h"
MyInt a2() { return a(); }

Generated SourceKit Swift interface for A2 starts with an import A statement, which is exactly what I would expect.

However, if the modules are nested, the import statement is not there:

module mods {
    module A {
        header "a.h"
        export *
    }
    module A2 {
        header "a2.h"
        export *
    }
}

and the generated interface for mods.A2 only contains the func a2() declaration, so the interface uses the MyInt type which is not defined in it.

I have a couple of questions:

  1. Is this the expected behavior?
  2. Is there a way to make sure the import statement is generated even for the nested situation? Perhaps some modulemap keyword, or a SourceKit argument.

Thanks!

2

I do think it would be reasonable to show the import statement here too; however, what are you actually trying to accomplish? The generated interface for imported APIs isn't meant to be consumed in an automated fashion (except perhaps for reformatting).

3

Thank you @jrose!

I'm experimenting with the WinSDK library: it is split into many different submodules, some of which depend on each other, but the generated interfaces don't indicate that.
I think it would be nice to see all the imports in the generated header to give a better impression of the submodule's dependencies.

I think I'll send a PR with this change.

1 Like