[pull] katei/swiftwasm from swiftwasm #18
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We have no working linker.
WebAssembly doesn't have __builtin_return_address.
This matches what Clang does. This doesn't check that the target is Wasm; will need to do that. Patcheng's port seems to have working? atomics, so it's probably possible to get atomics working, but this is fine for now. This still doesn't get the stdlib to compile, but at least the error now matches what I get when I run clang on the -emit-ir LLVM IR output.
This doesn't take care of all the PC relative relocations in constant builder yet. This still breaks on `((.Lgot.$sSTMp.656-($ss18EnumeratedSequenceVMn))-56)+1` Which sits in rodata. Not sure where that's generated yet
This removes the PCRel reloc in \01l_type_metadata_table but nowhere else
This at least seems to get rid of all the PCRel relocations emitted. Now it crashes in: (($sSTMp)+48)-8 The expr type is 0 expression kind not supported yay?!
This is completely untested.
Swift's importer won't import error constants from WASI, because the constants are wrapped in UINT16_C(), which Swift doesn't support.
LLVM doesn't support generating DWARF5 debugging data for WebAssembly, and support for atomics is currently very limited. Set LLVM target options to avoid generating DWARF5 debug data and lower atomics to regular load/stores when building for WebAssembly. This shouldn't affect existing platforms.
This allows running build commands in a reproducible way either locally or with any other CI. * Move CI build commands to separate scripts * Run CI on pushes to `swiftwasm` branch * Split build and setup steps into separate scrtipts * Fix execution directories in the build scripts
New WASI SDK package should contain a new version of the linker. Also, the script should now create an installable package on macOS so that one could create a full SwiftWasm package later after the build. * Update WASI SDK, create installable package on macOS * Fix sysroot path, update wasi-sdk on Linux * Exclude module net for wasm SDK in glibc.modulemap * Remove module termios from glic.modulemap for wasm * Disable _stdlib_mkstemps for wasm
`SymbolLookup.swift` was added recently, which broke our builds after rebasing on top of Apple's `master`. Using anything from this file wouldn't make sense on WebAssembly. It looks there are no codepaths that would call it on that platform, but there are still references to it around, so it has to be at least compilable.
Any changes in this repository should be tested with the packaging script and a basic smoke test that compiles `hello.swift` on CI. In the future packaging and linking scripts should be moved to this repository, `swiftwasm-sdk` and `swiftwasm-package-sdk` projects probably would be archived when that happens. For now we're pulling the scripts from `swiftwasm-package-sdk` as it is. * Run packaging scripts and smoke test on CI * Make prepare-package.sh executable * Make SymbolLookup.swift compilable for wasm * Use GitHub Actions upload/download steps * Remove packaging steps from ci-*.sh * Move prepare-package.sh to main.yml to avoid clone * Refine formatting in .github/workflows/main.yml
It would be convenient if packaged SDK and result of the smoke test were uploaded as artifacts of the CI run and become downloadable for later use. * Add more logging to the smoke test * Add a newline to main.yml * Upload packages and hello.wasm as CI artifacts * Normalize filenames for swiftwasm-package-sdk * Add macos_smoke_test job
Currently our CI scripts rely on validity of scripts in the [`swiftwasm-package-sdk`](https://github.com/swiftwasm/swiftwasm-package-sdk) repository. That can't always be the case, especialy as we don't checkout a specific commit in that repository. And even if we did, managing this isn't convenient. Adding a submodule has its own set of issues and I personally think that a monorepo approach is much simpler for a small set of scripts, at least at an early stage. In fact, it would make sense to have these scripts in the upstream [`swift`](https://github.com/apple/swift) repository at some point, similarly to [what Android people have previously done](https://github.com/apple/swift/tree/master/utils/android). Thus, these scripts and a few small helper files are copied to `utils/webassembly` directory and are executed directly on CI. After this PR is merged, I don't see a particular need for our [`swiftwasm-package-sdk`](https://github.com/swiftwasm/swiftwasm-package-sdk) and [`swiftwasm-sdk`](https://github.com/swiftwasm/swiftwasm-sdk) repos, those probably can be archived. As a small cleanup addition, `.github/workflows/main.yml` file now has consistent indentation. * Move packaging scripts from swiftwasm-package-sdk * Rename `wasm` directory to `webassembly` * Make all .sh scripts executable after download * Make sdkroot/swiftwasm script executable * Add newline to build-mac-package.sh * Add newline to build-packages.sh * Remove swift_start.o and swift_end.o
This PR fixed my runtime implementation in SwiftRT. I've inserted dummy `char` data in each metadata sections to ensure that all start/stop symbols are generated in swiftwasm#11. But of cource this dummy data can be inserted anywhere in the section, so metadata sections were broken by this 1 byte. I changed to link these start/stop symbols weakly. Non-generated start/stop variables get to be uninitialized. So `stop-start` results 0 length, and runtime library can avoid to load empty section. After this and swiftwasm#6 are merged, `print("Hello")` will work again! 🎉
Changed to make thunk to convert thin-to-thick and non-throws-to-throws.
We needs it on WebAssembly host because WASM checks number of arguments strictly for indirect function call.
This patch allows you to run the Swift code below.
```swift
func f(_ a: (Int) -> Void) {
g(a)
}
func g(_ b: (Int) throws -> Void) {
try! b(1)
}
f { _ in }
```
`wasm` was replaced with `wasi` in the platform triple, the packaging scripts are now updated accordingly.
* Bump macOS to 10.15 in GitHub Actions Potentially this should enable switching to Xcode 11.2.1 and even 11.3 when the latter is available. * Use macos-latest image in main.yml
* Remove fakeld It isn't needed if we don't try to build dynamic libraries for WASM. * Don't build StdlibUnittestFoundationExtras when cross-compiling on Darwin * Build static SDK overlay on WASI
* [WASM] Re-enable test targets * [WASM] Support WASI OS target for lit.cfg * [WASM] Link wasm32-wasi-unknown to wasm32-wasi * [WASM] Add sysroot to clang_linker to find crt1.o * [WASM] Separate WebAssembly test from linux * [WASM] Add static-executable-args.lnk for wasm * [WASM] First support of wasm in autolink-extract * [WASM] Extract link flags from named data segment from wasm object file * [WASM] Fix stdlib build on Linux * [WASM] Fix ICU lib flag to specify lib file instead of dir * [WASM] wip * [WASM] Iterate all configured sdks * [WASM] Remove object format specific code from macro * [WASM] Copy libswiftImageInspection.a to lib/swift_static/wasi * Use brew installed clang because Xcode version is old * [WASM] Fix new wasm/wasi triple * [WASM] Run executable test on wasmtime * Fix typo * [WASM] Cut environment from triple * Move build script into wasm dir * Run test on CI * Cleanup unused scripts * [WASM] Use -static instead of -static-executable to work emit-library * Proxy arguments to build-script * Ignore test failure temporarily * Fix packing command * Add missing x * Use wasi-sdk's clang compiler * [WASM] Avoid to build BlocksRuntime temporary due to os toolchains's clang limitation * [WASM] Comment out utime.h from glibc * [WASM] Change sysroot dir as wasi-sysroot * [WASM] Avoid to build BlocksRuntime on linux * [WASM] Add mman flag for wasi This eliminate clang hack which defines _WASI_EMULATED_MMAN as a predefined macro in clang ref: swiftlang/llvm-project@swift/master...swiftwasm:swiftwasm#diff-773abe7c69fccf723aa2d75447faa136R63-R66 * [WASM] Use latest wasi-sdk * [WASM] Avoid to build swift-reflection-test temporarily * [WASM] Install wasmtime on CI * [WASM] Set wasm as primary target to avoid to build SwiftRuntimeTests * [WASM] Fix macro arguments validation * [WASM] Copy ICU libs into toolchain * [WASM] Fix to specify libicu on mac * Remove extra space from build scripts
* [WASM] Minimize dependences of pthread * [WASM] Built fakepthread as a part of swift project * [WASM] Always build WasiPthread as static * [WASM] Fix to emit libswiftWasiPthread.a in swift_static * [WASM] Remove unused header file
* [WASM] Remove rpath flag and link objects using llvm-ar instead of ar * [WASM] Disable objc interop for sil-func-extractor when targeting wasm * [WASM] Exclude test cases which use -enable-objc-interop * [WASM] Make availability_returns_twice.swift unsupoorted on wasi due to lack of setjmp
And use --skip-repository to clone without checking out swift repo And install new dependency python-six due to python3 migration
* [WASM] Disable mmap test case for WASI OS due to lack of WASI API * [WASM] Disable simd test case for WASI OS simd api maybe stable in future https://github.com/WebAssembly/simd * [WASM] Fix to build pthread pollyfill only when wasi sdk * [WASM] Implement parsing command line arguments * [WASM] Run StdlibUnittest in process instead of child proc
kateinoigakukun
pushed a commit
that referenced
this pull request
Apr 16, 2020
New versions of Python warn if the literal is not escaped. Specifically:
"Support for nested sets and set operations in regular expressions as in
Unicode Technical Standard #18 might be added in the future. This would
change the syntax. To facilitate this future change a FutureWarning will
be raised in ambiguous cases for the time being. That include sets
starting with a literal '[' or containing literal character sequences
'--', '&&', '~~', and '||'. To avoid a warning, escape them with a
backslash. (Contributed by Serhiy Storchaka in bpo-30349.)"
https://docs.python.org/dev/whatsnew/3.7.html
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]. Want to support this open source service? Please star it : )