[GSoC 2017] Porting Swift to Haiku - Week #8
Since last week I worked on enabling Haiku support for running the swift test-suite. This allows the newly built compiler to be put through the same series of test-cases run by the swift buildbots for macOS, Linux and FreeBSD platforms. These tests cover different areas of the toolchain, from simple unit-tests to validation-tests that cover the compiler internals, major standard library API changes and most importantly, compiler stability via testing with malformed inputs. I ran the Swift 3.1 tests with the command
./utils/build-script -R -x , in which 2022 tests passed and 149 failed. A brief summary of the test results can be found here, and a list of the tests that have failed.
These failures seem to be related to the missing SDK paths or the system header locations not being passed down to the test-suite. Moreover, some of the tests that failed were only supported on macOS/iOS simulator platforms, thus are unsupported by all other platforms. I had to adapt these changes by adding Haiku to any test that is known to fail or be unsupported by Glibc platforms. This significantly reduced the number of failures Haiku was receiving, but more Glibc testing still needs to be done. Apart from that, I added support for using the swift integrated REPL (Read-Eval-Print-Loop), which is very useful for testing purposes, as you can see in the screenshot below:
I've also migrated and adapted all my Swift 3.1 work and rebased these patches to the upstream master branch, plus I'll be targeting Swift 4 via the swift-4-haiku-support branch. Due to tickets #8798, #7859 (thanks phoudoin!), #11124 and #13601 being either fixed or pending to be upstreamed, I've removed some of my workarounds and will be cleaning up my patches to avoid potential conflicts on my branch. Any patches that are unsuitable for upstream will have to be remain as a patchset in HaikuPorts.
Porting the foundation-libraries will be the next focus area after testing the compiler. These libraries hold extended functionality outside of the default standard libraries and are very important for using other 3rd party libraries. The swift recipe will be updated to include the above fixes, then I'll add a recipe for 4.0 afterwards.
- No, I'm not Haiku's lead developer
- Haiku monthly activity report - 12/2019
- Haiku almost-monthly activity report - October and November 2019
- Haiku monthly activity report - September 2019
- Node.js now available in Haiku
- Haiku monthly activity report - 08/2019
- GSOC 2019 Final Report
- Haiku Activity Report: Performance Edition
- new PVS studio scan
- Coding week 4,5,6