Use the new Android overlay and Bionic module from Swift 6

[finagolfin]

Motivation:

Get this repo building again for Android with the new overlay

Modifications:

• Import the new module or overlay wherever Glibc is used
• Keep this repo building with Swift 5 by duplicating some declarations

Result:

All the same tests keep passing on my Android CI, finagolfin/swift-android-sdk#158

I imported the smaller Bionic module where possible, and only used Android when files invoked C functions not in the new Bionic module, swiftlang/swift#72161.

[finagolfin]

Previously, all these constants couldn't be automatically set by the ClangImporter from the C headers, but now only this one constant couldn't, because it's the only one that's a C macro.

[FranzBusch]

@finagolfin Thanks for the PR. Relatedly I have been wondering if we could setup GH action based Android testing in this repo in the long term?

I would interested to hear what your thoughts are and how we can make developing for Android as easy as installing a cross compilation SDK.

[finagolfin]

Thanks for the quick review, a github action CI workflow for Android on this repo would be great. 😄

I plan to start distributing an Android SDK bundle, which would obsolete the additional local configuration required for my current Android SDK, and then look into putting together a custom github build action that any Swift package can use with that new SDK bundle for their own CI, finagolfin/swift-android-sdk#127.

If you would like, I can submit an Android CI workflow for this repo when that SDK bundle is ready. However, my daily Android CI already tests this repo and I quickly upstream most changes needed, so I'm fine with that cadence too. It really just depends if you want to know about Android breaks with every pull, and given that Android is not an officially supported platform, I'm fine with not imposing that additional requirement on NIO pull authors for now.

[FranzBusch]

If you would like, I can submit an Android CI workflow for this repo when that SDK bundle is ready. However, my daily Android CI already tests this repo and I quickly upstream most changes needed, so I'm fine with that cadence too. It really just depends if you want to know about Android breaks with every pull, and given that Android is not an officially supported platform, I'm fine with not imposing that additional requirement on NIO pull authors for now.

In the fullness of time I would like to have Android support in all the repos as well. This would require a few things:

• The cross compilation SDK bundle
• Pitching Android as an officially supported language for Swift.

Once we tackle the latter we might be able to distribute this cross compilation bundle on swift.org which would unlock us testing this in our GitHub Actions.

[finagolfin]

Pitching Android as an officially supported language for Swift

Already done and I think provisionally agreed to by the core team members I talked to. I will know for sure once I submit it as part of the official CI, which has only been delayed by me.

Once we tackle the latter we might be able to distribute this cross compilation bundle on swift.org which would unlock us testing this in our GitHub Actions.

Yes, once I'm distributing my own Android SDK bundle and then if and when Android becomes officially supported, distributing an official Android SDK bundle like the current official linux static SDK bundle would be the next step.

We can try setting up an Android CI action for this and other Swift repos then, let's see.

[finagolfin]

Rebased and fixed merge conflicts, anything holding up review here?

[FranzBusch]

@finagolfin can you just fix up the formatting then we can merge it

[finagolfin]

Will do.

[finagolfin]

Ran swift format like on the CI and updated this pull.