Fix two issues with the SwiftGlibc module map

[martinboehme]

The issues are:

• Today, some submodules in SwiftGlibc fail to provide definitions that they should contain. As a consequence, Swift fails to import some code that compiles correctly with standalone Clang. As just one example, including signal.h should make the type pid_t available, but it currently does not.

• SwiftGlibc is not compatible with the libc++ module map. Trying to include libc++ headers in a C++ module imported into Swift results in an error message about cyclic dependencies.

This change fixes both of these issues by making it so that SwiftGlibc no actually longer defines a module map for the glibc headers but merely makes all of the symbols from those headers available in a module that can be imported into Swift. C / Objective-C / C++ code, on the other hand, will now include the glibc headers texually.

For more context on the two issues and this fix, see this forum discussion:

https://forums.swift.org/t/problems-with-swiftglibc-and-proposed-fix/37594

This change only modifies glibc.modulemap.gyb for the time being but leaves bionic.modulemap.gyb and libc-openbsd.modulemap.gyb unchanged. The intent is to fix these in the same way, but it will be easier to do this in separate PRs that can be tested individually.

[martinboehme]

@swift-ci Please test

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - a0ec0fd16b6350065ace857cdae8df9e2988762d

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - a0ec0fd16b6350065ace857cdae8df9e2988762d

[martinboehme]

@swift-ci Please test OS X

[martinboehme]

A fix for the broken test on Linux is in progress at #32465.

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 7efdc17714aa0b70efcb195e444944c58e2c8c5b

[martinboehme]

Build failed
Swift Test OS X Platform
Git Sha - 7efdc17

This is failing with what looks like an unrelated error:

/Users/buildnode/jenkins/workspace/swift-PR-osx/branch-master/swift/test/Constraints/operator.swift:223:26: error: incorrect message found
09:06:03   // expected-error@-1 {{referencing operator function '==' on 'Array' requires that 'Dictionary<String, E>.Values' conform to 'Equatable'}}
09:06:03                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
09:06:03                          operator function '==' requires that 'Dictionary<String, E>.Values' conform to 'Equatable'

[shahmishal]

Please update the base branch to main by Oct 5th otherwise the pull request will be closed automatically.

• How to change the base branch: (Link)
• More detail about the branch update: (Link)

[zoecarver]

@swift-ci please smoke test.

[zoecarver]

@swift-ci please smoke test linux platform.

[zoecarver]

(This comment is just so I remember what needs to be done.) To get the Linux build green we need to remove the @_implementationOnly decorator from before import CoreFoundation in three files in swift-corelibs-foundation: Sources/Foundation/Data.swift, Sources/Foundation/NSLock.swift, and Sources/Foundation/Thread.swift.

[scentini]

@swift-ci please smoke test linux platform.

[zoecarver]

@scentini see my above comment. We're going to need to update those three files to get the Linux build working.

[scentini]

@zoecarver we are looking into fixing @_implementationOnly instead, see SR-13785.

[zoecarver]

@zoecarver we are looking into fixing @_implementationOnly instead, see SR-13785.

Oh, great. That's the better way to fix this :)

[hlopko]

@swift-ci please test

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 968f3350373858d0e167b52fc6a102eec8c48dfd

[hlopko]

@swift-ci please test

[hlopko]

We'd like to move forward with this PR. If nobody objects by Monday, we'll submit. We're happy to address all post-submit review comments. Thanks!

[zoecarver]

FWIW this LGTM. Ship it.

[drodriguez]

Not a blocker: Bionic (Android) has a different modulemap (stdlib/public/Platform/bionic.modulemap.gyb), which this PR doesn't change. From my understanding of forum post and the changes in this PR, it should be possible to do the same in Android and remove the specific module map, right?

Once this lands, another PR can be created to do that, no need to change this PR at all (specially because the Android CI cannot be requested for a PR, so checking that it works would be complicated).

[finagolfin]

@drodriguez, anybody working on the Android version of this pull? I can put it together if noone else is.

@3405691582, you may want to do the same for OpenBSD.

[drodriguez]

@buttaface I had the first step working (removing the complicated modulemap), but the test were failing. In the Android case, I think mostly because of the cross-compilation. These weekends have been quite busy and I haven't had time to work on anything, so if you want to have a try at this, feel free. Also, sorry for not being able to test and merge the other PR you had open. I will try to make time at some point.

[finagolfin]

@drodriguez, no problem, I figured you were busy. If we get this modulemap change in first, we may not need to modify that C++ test in the NDK pull, so I will try to get this working first.