Commands: enable the parseable module interface by default

[compnerd]

Enable the swift module interface to be emitted by default. This is helpful for API surface tracking and can potentially enable perusal of the swiftinterface in VSCode mirroring what XCode already permits.

[compnerd]

@swift-ci please smoke test

[compnerd]

CC: @artemcm

[xymus]

CC @bnbarham As we've been considering generating more swiftinterfaces for our own tools too.

[xymus]

We've been considering such a change to feed the swiftinterfaces to more tools ourselves.

We may want to have something in the compiler to prevent (or warn) when building from a non-resilient swiftinterface if that becomes a problem.

[bnbarham]

This is helpful for API surface tracking and can potentially enable perusal of the swiftinterface in VSCode mirroring what XCode already permits.

It's worth noting that Xcode doesn't use the .swiftinterface, but rather a "generated interface". It avoids printing underscored attributes, allows grouping APIs, synthesizes extensions, and prints comments. There's different entry points for a module/swift file/header - see eg. editorOpenInterface in Requests.cpp.

Having said that, as long as we avoid building from a .swiftinterface for non-resilient modules (which could just be a check of the args in the .swiftinterface), I don't see anything wrong with this change. If comments were added to the .swiftinterface perhaps we could also move towards removing .swiftdoc (and others?).

[compnerd]

We may want to have something in the compiler to prevent (or warn) when building from a non-resilient swiftinterface if that becomes a problem.

This seems reasonable to me. @bnbarham would you be okay with this being deferred as @xymus suggested?

It's worth noting that Xcode doesn't use the .swiftinterface, but rather a "generated interface". It avoids printing underscored attributes, allows grouping APIs, synthesizes extensions, and prints comments. There's different entry points for a module/swift file/header - see eg. editorOpenInterface in Requests.cpp.

Oh, that is interesting. Unfortunately, I don't think that VSCode likes the idea of generating, and it would require some work to do that, though if that is already in the LSP ... we might be able to write that out and point VSCode to the on-disk representation. The other features of that seem like conveniences that would be appreciated by users.

[bnbarham]

This seems reasonable to me. @bnbarham would you be okay with this being deferred as @xymus suggested?

That's fine with me. It shouldn't be an issue right now as we prefer swiftmodules. Just something to keep in mind going forward.

The other features of that seem like conveniences that would be appreciated by users.

I personally prefer the idea of using the swiftinterface and possibly unifying the other files into it.

[compnerd]

@swift-ci please smoke test

[xymus]

I happened to add something that was missing for the compiler to be able to detect when building against a non-library-evolution enabled swiftinterface. So I went ahead and started working on reporting it: swiftlang/swift#61765

Note that there's still a warning when generating a swiftinterface for a non-libary-evolution module.

[neonichu]

Note that there's still a warning when generating a swiftinterface for a non-libary-evolution module.

I think as long as that is the case, we can't really enable it by default.

[tomerd]

cc @elsh in case this impact the ideas you are working on

[neonichu]

@compnerd should we close this one?