WinSDK: explicitly re-export ucrt

[egorzhdan]

ucrt symbols are already implicitly available after an import WinSDK statement, however, WinSDK generated Swift interface does not indicate that.

Besides, WinSDK Swift overlay uses time_t in its public interface, which is declared in ucrt, but there is no corresponding import statement.

This change adds the import statement, to make the dependencies & exports more clear for the users, and to help with IDE integration.
The generated Swift interface for WinSDK after this change contains an import ucrt statement.

[compnerd]

Im not sure how I feel about this. This is roughly similar to say UIKit exporting Darwin.C. How does this improve the usage scenarios for WinSDK?

[egorzhdan]

This is mostly to make sure the generated Swift interface for WinSDK reflects what symbols are already being exported from it – ucrt contents were exported before this change, but the generated interface didn't indicate that. Exporting CRT rather than ucrt seemed like a good idea to me, but I can narrow it down to just ucrt if you disagree. That would fully solve the issue as well.

In practice this means that, for example, code referencing __crt_bool (or anything else declared in ucrt) without import ucrt statement would unexpectedly compile without errors given that import WinSDK is present, however, IDEs or static analysis tools would likely choke up on the usage of an undeclared symbol (this was my main motivation behind this PR).

This is roughly similar to say UIKit exporting Darwin.C

There's a difference though: UIKit has a Swiftified interface & is supposed to be used directly, while WinSDK would more likely be used via Swifty wrappers rather than directly, due to lots of rough edges caused by automatic C-to-Swift conversion, especially around pointers & strings.

[compnerd]

ucrt is part of WInSDK, the thing is that CRT also exposes visualc which is technically more than just the WinSDK aspect. ucrt actually even resides in WinSDK (ucrt.modulemap is copied into Windows Kits\10\Include\...\ucrt), so I think I could be convinced that this is not too terrible. I wonder if we can adjust the WinSDK module in some other way to not conflate the C library with the Windows SDK.

There's a difference though: UIKit has a Swiftified interface & is supposed to be used directly, while WinSDK would more likely be used via Swifty wrappers rather than directly, due to lots of rough edges caused by automatic C-to-Swift conversion, especially around pointers & strings.

If there are simple things that can be done to improve the ergonomics of the WinSDK module, I think that we should consider adding them to the module. The raison d'être of the WinSDK (Swift) module is to ease the use of the clang module, otherwise we wouldn't need the module at all. I just haven't figured out a nice simple adjustment for the interfaces that eases the access.

[egorzhdan]

CRT also exposes visualc

Oh that's a fair point, I didn't realize that. Switched the import to just ucrt instead of CRT.

I wonder if we can adjust the WinSDK module in some other way to not conflate the C library with the Windows SDK.

I'm not sure it's possible to avoid exporting ucrt from WinSDK – it seems to be caused by the include-directive-to-module transformation, not by Swift-specific logic.

[compnerd]

I wonder if we can adjust the WinSDK module in some other way to not conflate the C library with the Windows SDK.

I'm not sure it's possible to avoid exporting ucrt from WinSDK – it seems to be caused by the include-directive-to-module transformation, not by Swift-specific logic.

The include should convert to an import, of the module, which is a dependency of course. This changes the module to re-export the the dependent module.

My concern with this is just that the WinSDK module should not be vending the C library is all.

[compnerd]

@swift-ci please smoke test