Elliott Williams

> If it is necessary, it must be generated during the build. It is not acceptable for us to maintain these non-autogenerated modulemap. I worked with @adetaylor on this, and...

Pushed a small refactor to get internal builds working—unfortunately, I don't see an obvious way for the internal SDK check to work inside the handwritten .swiftmodule. `@_exported @_spi(...) import Foo`...

There's clearly more work to do to make the public builds happy.

@aproskuryakov asked me about this in person, so for posterity, here's what one of the generated .swiftinterface files looks like. arm64-apple-macos.swiftinterface: ```swift // swift-interface-format-version: 1.0 // swift-compiler-version: Apple Swift version...

The latest revision moves the bincompat symlink creation step to `WebKitSwiftOverlay.xcodeproj`. This is to satisfy Apple's internal OS build system, which expects that this project continues to produce `./usr/lib/swift/libswiftWebKit.dylib` and...

> The latest revision moves the bincompat symlink creation step to `WebKitSwiftOverlay.xcodeproj`. This is to satisfy Apple's internal OS build system, which expects that this project continues to produce `./usr/lib/swift/libswiftWebKit.dylib`...

Holding off on landing this as we discuss what the correct behavior actually is.

Stacked on top of #45871, please review the first commit there.

> > Since changes to type annotations can cause failures at distant call sites, I believe it's appropriate to treat them as unit tests rather than a style check. >...