Add support for Embedded Swift

[grynspan]

Add support for Embedded Swift:

• Audit our platform-specific code and add branches for Embedded Swift based on what we can assume is available in a standards-compliant libc.
• Get embedded hardware (Raspberry Pi or some such)
• Set up CI jobs

Above and beyond other porting efforts:

• Figure out how to run tests on an embedded system (cross-platform build-and-run using SwiftPM)
• Figure out what features are possible with Embedded Swift and which will be unavailable

[grynspan]

Tracked internally as rdar://145678965.

[MaxDesiatov]

FWIW you don't need to own embedded hardware to test Embedded Swift support in general. Embedded Swift is just as useful for Wasm, and a compatible Wasm runtime is available in any major browser.

[grynspan]

I'm aware Wasm is a valid Embedded Swift target, but I don't think we could reasonably qualify our support for Embedded Swift with just Wasm. We already have affordances for WASI and Wasm in the codebase and they may or may not translate to other platforms/architectures/etc., so we'd want to make sure things work elsewhere too.

[tdcox]

My recommendation would be to consider the ESP32 use-case since this covers all the special cases likely to be encountered in the embedded space. Hardware is also cheaper.

I would envision that there are at least three scenarios that need consideration:

1. Testing Swift 'business logic' on the host machine - compiling for the host and executing tests locally as part of the build. This is limiting, as you aren't testing the ultimate output (which will be cross-compiled for another target) but does at least allow you to test core logic as part of a simple build.

2. Testing on target hardware - cross-compiling and then launching a test suite on target hardware and collecting results. This scenario allows the testing of 'real' code but requires a testing framework that can execute on the target hardware. This also requires some modifications to the build process since the code under test must be bundled with a test framework and deployed to test hardware. Tests will then run asynchronously on that hardware and the results must be captured and returned to the build pipeline where they are evaluated. If passing, the build must then create the final production application and deploy that to target hardware (which may be a different instance to the test hardware).

3. Testing on emulated hardware - cross-compiling and then launching a test suite on a simulator / emulator running on the host. This is similar to scenario 2 but removes the need for physical hardware. Not all tests will be amenable to running under emulation and performance will be significantly different compared to physical hardware, leading to a high risk of race conditions and similar timing related issues producing false positives or false negatives.

Practically speaking, it is likely that teams will need to be able to use more than one of the options above in order to get appropriate coverage, since each approach has different limitations with regard to external dependencies like FreeRTOS libraries or hardware support. This introduces a need for multiple build targets.

There are some build-related challenges that creep in too. For example, ESP32-builds are leveraging the IDF build process, so unit tests need to be invoked as part of that build pipeline rather than as per SwiftPM norms.

[grynspan]

Thanks for the suggestion! We have a lot of options for hardware to test on; Raspberry Pi as suggested in the description above is just a well-known example. I suspect it will come down to the preferences and/or budget of each contributor (or that contributor's employer.)

[hrayatnia]

@grynspan, ESP32 and STM32 are more affordable and widely used in the industry in compare to Raspberry Pi (except for Raspberry Pi Pico).

[grynspan]

As I wrote earlier, Raspberry Pi is just an example and hardware selection is going to be at each contributor's discretion.

[hrayatnia]

@grynspan Quick question, should I check for Non-allocating Embedded Swift while I'm auditing the code? Or only for the current embedded Swift version?

Also, for setting up CI, I'm not sure if I have sufficient access.

[grynspan]

Our code does not build for Embedded Swift yet.

We expect (heh) to initially require allocating/locking in our minimum supported configuration.

[hrayatnia]

@grynspan It is not my intention to frustrate or bother you. Sorry if I did unintentionally.
I'm aware of the fact that the code doesn't build for embedded Swift yet.

I feel like I misunderstood the scope of the issue. I was auditing the current code base to provide a report, then add branches for Embedded Swift based on what we can assume is available in a standards-compliant libc. I guess I have to wait for the future platform (embedded) specific code 😅.

[grynspan]

I'm not bothered!

There are a number of compiler-side changes we need before we can begin supporting features of Swift Testing in Embedded Swift. This work is not planned for Swift 6.2. If you're interested in contributing I might suggest looking at some of the other open issues we have (especially around alternative platform support if that interests you!)