Proof/rebase/swiftwasm/2020 01 12#11
Closed
kateinoigakukun wants to merge 681 commits into
Closed
Conversation
…-types-in-swiftinterface Clang function types v2: Electric Boogaloo (parsing + printing)
MSVC did not like the original code and would fail to build as: ``` swift\include\swift/Basic/Located.h(50): error C2995: 'bool swift::operator ==(const swift::Located<T> &,const swift::Located<T> &)': function template has already been defined swift\include\swift/Basic/Located.h(50): note: see declaration of 'swift::operator ==' llvm\include\llvm/Support/TrailingObjects.h(76): note: see reference to class template instantiation 'swift::Located<swift::Identifier>' being compiled llvm\include\llvm/Support/TrailingObjects.h(233): note: see reference to class template instantiation 'llvm::trailing_objects_internal::AlignmentCalcHelper<swift::Located<swift::Identifier>>' being compiled swift\include\swift/AST/Decl.h(1512): note: see reference to class template instantiation 'llvm::TrailingObjects<swift::ImportDecl,swift::Located<swift::Identifier>>' being compiled ``` The original code is odd. There appears to be some unnecessary complexity. First, the member function is marked as a friend of a `struct` type which does not change the member's visibility, thus all the members are `public`, and the function need not be friended. Second, the function is templated over the same parameter type, which means that the original template parameter could be used and the standard member equality operator could be used rather than the free-standing form. It is unclear why the member equality operator is insufficient, and the extraneous template instatiations here seem wasteful. Out-of-line the free-standing form and not mark it as a friend to restore the build. Switching to a member form can be a follow up change.
…wiftlang#29025) Xcode's new build system requires the Version entry in Info.plist to have a particular date-based format. Toolchains built using utils/build-toolchain now work with Xcode's new build system.
I have been using this in a bunch of places in the compiler and rather than implement it by hand over and over (and maybe messing up), this commit just commits a correct implementation. This data structure is a map backed by a vector like data structure. It has two phases: 1. An insertion phase when the map is mutable and one inserts (key, value) pairs into the map. These are just appeneded into the storage array. 2. A frozen stage when the map is immutable and one can now perform map queries on the multimap. The map transitions from the mutable, thawed phase to the immutable, frozen phase by performing a stable_sort of its internal storage by only the key. Since this is a stable_sort, we know that the relative insertion order of values is preserved if their keys equal. Thus the sorting will have created contiguous regions in the array of values, all mapped to the same key, that are insertion order. Thus by finding the lower_bound for a given key, we are guaranteed to get the first element in that continguous range. We can then do a forward search to find the end of the region, allowing us to then return an ArrayRef to these internal values. The reason why I keep on finding myself using this is that this map enables one to map a key to an array of values without needing to store small vectors in a map or use heap allocated memory, all key, value pairs are stored inline (in potentially a single SmallVector given that one is using SmallFrozenMultiMap).
…g-types-in-swiftinterface Revert "Clang function types v2: Electric Boogaloo (parsing + printing)"
…ctic-walker-setup [swift-ide-test] Mimic SourceKit's setup when testing syntactic requests
Basic: out-of-line equality operator (NFCI)
[NFC] Hide SourceFile::Decls
…pty builtin types. The RemoteMirror library in shipping versions of macOS/iOS/tvOS/watchOS crashes if the compiler emits a BuiltinTypeDescriptor with size zero. Although this is fixed in top-of-tree RemoteMirror, we want binaries built with the new compiler to still be inspectable when run on older OSes. Generate the metadata as an empty struct with no fields when deploying back to these older platforms, which should be functionally equivalent for most purposes. Fixes rdar://problem/57924984.
…n-apply Generalize solution application
…wiftmodule from .swiftinterface This change ensures using .swiftmodule built from source has the same behavior as using .swiftmodule built from .swiftinterface. A swift-ide-test utility is added to print linked libraries from a Swift module for testing purposes. rdar://58057556
…urce When force linking auto-linked libraries, an overlay will fail to link if the dependence libraries are missing from the source. This change provides linker flags to search overlay libraries from the SDK.
…61b19c13b8d192fba6aa6f2 [basic] Add a simple vector backed 2 stage multi map.
ModuleInterface: preserve AutolinkForceLoad option when generating .swiftmodule from .swiftinterface
Use the new EscapeAnalysis infrastructure to make ARC code motion and ARC sequence opts much more powerful and fix a latent bug in AliasAnalysis. Adds a new API `EscapeAnalysis::mayReleaseContent()`. This replaces all uses if `EscapeAnalysis::canEscapeValueTo()`, which affects `AliasAnalysis::can[Apply|Builtin]DecrementRefCount()`. Also rewrite `AliasAnalysis::mayValueReleaseInterferWithInstruction` to directly use `EscapeAnalysis::mayReleaseContent`. The new implementation in `EscapeAnalysis::mayReleaseContent()` generalizes the logic to handle more cases while avoiding an incorrect assumption in the prior code. In particular, it adds support for disambiguating local references from accessed addresses. This helps handle cases in which inlining was defeating ARC optimization. The incorrect assumption was that a non-escaping address is never reachable via a reference. However, if a reference does not escape, then an address into its object also does not escape. The bug in `AliasAnalysis::mayValueReleaseInterfereWithInstruction()` appears not to have broken anything yet because it is always called by `AliasAnalysis::mayHaveSymmetricInteference()`, which later checks whether the accessed address may alias with the released reference using a separate query, `EscapeAnalysis::canPointToSameMemory()`. This happens to work because an address into memory that is directly released when destroying a reference necesasarilly points to the same memory object. For this reason, I couldn't figure out a simple way to hand-code SIL tests to expose this bug. The changes in diff order: Replace EscapeAnalysis `canEscapeToValue` with `mayReleaseContent` to make the semantics clear. It queries: "Can the given reference release the content pointed to the given address". Change `AliasAnalysis::canApplyDecrementRefCount` to use `mayReleaseContent` instead if 'canEscapeToValue'. Change `AliasAnalysis::mayValueReleaseInterferWithInstruction`: after getting the memory address accessed by the instruction, simply call `EscapeAnalysis::mayReleaseContent`, which now implements all the logic. This avoids the bad assumption made by AliasAnalysis. Handle two cases in mayReleaseContent: non-escaping instruction addresses and non-escaping referenecs. Fix the non-escaping address case by following all content nodes to determine whether the address is reachable from the released reference. Introduce a new optimization for the case in which the reference being released is allocated locally. The following test case is now optimized in arcsequenceopts.sil: remove_as_local_object_indirectly_escapes_to_callee. It was trying to test that ARC optimization was not too aggressive when it removed a retain/release of a child object whose parent container is still in use. But the retain/release should be removed. The original example already over-releases the parent object. Add new unit tests to late_release_hoisting.sil.
…rnary operator `TernaryBranch` with a boolean flag to identify "then" (true) or "else" (false) branches of the ternary operator expression.
Rewrite AliasAnalysis may-release/may-decrement queries.
* Added more details to "Building Swift on Windows"
[Source Tooling] Refactoring action to convert to computed property
…iptor-workaround IRGen: Work around RemoteMirror bug generating reflection info for empty builtin types.
Newer clangs are more reliable about emitting templated methods that are marked "used".
docs: remove unused file
…ly (#9) `LIBC_INCLUDE_DIRECTORY` is used to generate `glibc.modulemap`. Currently the directory is set `/usr/include` but it's system header path and we should use `wasi-sdk` version.
* Add simple GitHub Actions config for macOS * Add brew install to the macOS GH action * Add update-checkout call to macOS GH action * Export sourcedir shell variable in macOS GH action * [WASM] Use prebuilt llvm-ar only on Linux * [WASM] Added new Object format WASM to distinguish from ELF * [WASM] Separate SwiftRT from ELF * [WASM] Add preprocessor condition for wasm32 to track latest upstream * Add wasi-sdk and icu install steps to the script * [WASM] Set LIBC_INCLUDE_DIRECTORY without CACHE attribute to force new value * [WASM] Adding share path to point correct directory * [WASM] Add Linux CI job * [WASM] Checkout branch after checking out Swift repos * [WASM] Use release build to reduce artifact size * [WASM] Use SWIFT_PRIMARY_VARIANT_SDK instead of HOST_SDK In this case, SWIFT_PRIMARY_VARIANT_ARCH is used but host SDK was not PRIMARY_SDK. * [WASM] Remove ICU_STATICLIB on Linux * [WASM] Output build log verbose * [WASM] Set ICU lib directory instead of archive * [WASM] Sort build options * Revert "[WASM] Use SWIFT_PRIMARY_VARIANT_SDK instead of HOST_SDK"
* [WASM] Build ImageInspectionShared even on macOS ImageInspectionShared was built only if host OS is Linux. But it's necessary when primary sdk is WASM. * [WASM] Use llvm-ar instead of ranlib on macOS Specify ar binary through extra-cmake-options * [WASM] Install llvm through HomeBrew to use llvm-ar * [WASM] Use llvm-ranlib instead of ranlib of Xcode * [WASM] Read offset as pointer when target is wasm Because WASM doesn't support relative pointer, compiler emit direct address instead of offset from current address. * [WASM] Copy SwiftRT-ELF.cpp into SwiftRT-WASM.cpp * [WASM] Emit empty swift5 sections if there aren't * [WASM] Remove swift_end and swift_start files
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
kateinoigakukun
added a commit
that referenced
this pull request
Jan 24, 2020
* [WASM] Build ImageInspectionShared even on macOS ImageInspectionShared was built only if host OS is Linux. But it's necessary when primary sdk is WASM. * [WASM] Use llvm-ar instead of ranlib on macOS Specify ar binary through extra-cmake-options * [WASM] Install llvm through HomeBrew to use llvm-ar * [WASM] Use llvm-ranlib instead of ranlib of Xcode * [WASM] Read offset as pointer when target is wasm Because WASM doesn't support relative pointer, compiler emit direct address instead of offset from current address. * [WASM] Copy SwiftRT-ELF.cpp into SwiftRT-WASM.cpp * [WASM] Emit empty swift5 sections if there aren't * [WASM] Remove swift_end and swift_start files
kateinoigakukun
added a commit
that referenced
this pull request
Jan 25, 2020
* [WASM] Build ImageInspectionShared even on macOS ImageInspectionShared was built only if host OS is Linux. But it's necessary when primary sdk is WASM. * [WASM] Use llvm-ar instead of ranlib on macOS Specify ar binary through extra-cmake-options * [WASM] Install llvm through HomeBrew to use llvm-ar * [WASM] Use llvm-ranlib instead of ranlib of Xcode * [WASM] Read offset as pointer when target is wasm Because WASM doesn't support relative pointer, compiler emit direct address instead of offset from current address. * [WASM] Copy SwiftRT-ELF.cpp into SwiftRT-WASM.cpp * [WASM] Emit empty swift5 sections if there aren't * [WASM] Remove swift_end and swift_start files
kateinoigakukun
pushed a commit
that referenced
this pull request
Mar 23, 2026
When the host compiler is built with assertions, 'swiftc -parse -'
hits an assertion failure, which fails the capability checks.
```
Assertion failed: [&]() -> bool { if (FrontendOptions::shouldActionOnlyParse(Action)) { return llvm::all_of( opts.InputsAndOutputs.getAllInputs(), [](const InputFile &IF) { const auto kind = IF.getType(); return kind == file_types::TY_Swift || kind == file_types::TY_SwiftModuleInterfaceFile; }); } return true; }() && "Only supports parsing .swift files", file C:\Users\swift-ci\jenkins\workspace\swift-main-windows-toolchain\swift\lib\FrontendTool\FrontendTool.cpp, line 1737
Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the crash backtrace.
Stack dump:
0. Program arguments: S:\\b\\toolchains\\DEVELOPMENT-SNAPSHOT-2025-12-01-a\\LocalApp\\Programs\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\bin\\swift-frontend.exe -frontend -parse -primary-file - -target x86_64-unknown-windows-msvc -disable-objc-interop -no-color-diagnostics -Xcc -fno-color-diagnostics -disable-implicit-string-processing-module-import -empty-abi-descriptor -no-auto-bridging-header-chaining -module-name main -in-process-plugin-server-path S:\\b\\toolchains\\DEVELOPMENT-SNAPSHOT-2025-12-01-a\\LocalApp\\Programs\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\bin\\SwiftInProcPluginServer.dll -plugin-path S:\\b\\toolchains\\DEVELOPMENT-SNAPSHOT-2025-12-01-a\\LocalApp\\Programs\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\bin -plugin-path S:\\b\\toolchains\\DEVELOPMENT-SNAPSHOT-2025-12-01-a\\LocalApp\\Programs\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\local\\bin -autolink-library oldnames -autolink-library msvcrt -Xcc -D_MT -Xcc -D_DLL
1. Swift version 6.3-dev (LLVM 35f48306184cd25, Swift a69dbb3)
2. Compiling with effective version 5.10
Exception Code: 0x80000003
#0 0x00007ff7a6efdda5 (S:\b\toolchains\DEVELOPMENT-SNAPSHOT-2025-12-01-a\LocalApp\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x722dda5)
#1 0x00007ff94d8b1989 (C:\WINDOWS\System32\ucrtbase.dll+0xc1989)
#2 0x00007ff94d894ab1 (C:\WINDOWS\System32\ucrtbase.dll+0xa4ab1)
#3 0x00007ff94d8b2986 (C:\WINDOWS\System32\ucrtbase.dll+0xc2986)
#4 0x00007ff94d8b2b61 (C:\WINDOWS\System32\ucrtbase.dll+0xc2b61)
#5 0x00007ff7a02d944d (S:\b\toolchains\DEVELOPMENT-SNAPSHOT-2025-12-01-a\LocalApp\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x60944d)
#6 0x00007ff7a02db914 (S:\b\toolchains\DEVELOPMENT-SNAPSHOT-2025-12-01-a\LocalApp\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x60b914)
#7 0x00007ff7a011b19e (S:\b\toolchains\DEVELOPMENT-SNAPSHOT-2025-12-01-a\LocalApp\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x44b19e)
#8 0x00007ff7a011ad57 (S:\b\toolchains\DEVELOPMENT-SNAPSHOT-2025-12-01-a\LocalApp\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x44ad57)
#9 0x00007ff7a6f667d0 (S:\b\toolchains\DEVELOPMENT-SNAPSHOT-2025-12-01-a\LocalApp\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x72967d0)
#10 0x00007ff94e6be8d7 (C:\WINDOWS\System32\KERNEL32.DLL+0x2e8d7)
#11 0x00007ff94fe2c40c (C:\WINDOWS\SYSTEM32\ntdll.dll+0x8c40c)
```
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
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.
Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.
Resolves SR-NNNN.