[pull] swiftwasm from main #635
Open
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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
…deallocated" in Linux foundation (swiftlang#4653) The reported error was an CFSTR("") which is later released. While this should not be a problem, the Linux implementation of CFSTR does not ignore dealloc on constant strings. Fixed this by calling CFRetain on the constant string. Strictly speaking this is only a workaround. Issue swiftlang#1351 has some hints how this could be fixed but the workaround is used a over the code so I think it is okay to use it here, too. I found the same problem in CFDateIntervalFormatter.c where it appeared in a error handling code path that should never be called. Fixed anyways.
Correct the implementation of `_NSCleanupTemporaryFile` to use `MoveFileExW` with `MOVEFILE_COPY_ALLOWED` to prefer to use file renames rather than copy and delete. This should improve performance in the general single volume case and still allow the correct behaviour in the multi-volume scenarios using `CopyFile` and `DeleteFile`. Thanks to @darinf for identifying the test case with 65535 temporary files!
Fix `JSONEncoder.OutputFormatting.sortedKeys` behavior
…hange_strong_explicit The failure memory order cannot be release or acq_rel. Clang since llvm/llvm-project@fed5644 diagnoses an invalid argument.
…om a sequence of bytes. (swiftlang#4813)
Fixes swiftlang#4735. Xcode 14 introduced the `NSLocking.withLock(_:)` method to the Darwin implementation of Foundation. This commit adds the new method to the open-source implementation. (Note: The [documentation](https://developer.apple.com/documentation/foundation/nslocking/4059821-withlock) incorrectly specifies the availability of the method as iOS 16+, etc. but it is actually available on all OS versions because it is marked [`@_alwaysEmitIntoClient`](https://github.com/apple/swift/blob/main/docs/ReferenceGuides/UnderscoredAttributes.md#_alwaysemitintoclient). The documentation bug is tracked by [FB11968310](https://feedbackassistant.apple.com/feedback/11968310).) I copied the implementation from `Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/System/Library/Frameworks/Foundation.framework/Modules/Foundation.swiftmodule/arm64e-apple-ios.swiftinterface`.
[runloop] Fix the failure memory order argument to atomic_compare_exchange_strong_explicit
…H_API This is a follow-up to 5e7281b
BlocksRuntime uses dlsym to find objc_destructInstance, which is not available on all platforms. This change adds a check for dlfcn.h and only uses dlsym if it is available and otherwise crashes the program. The crash will not usually happen, as `_Block_use_RR` is only called from objc-auto, which is not available for such platforms.
Xcode 15 no longer recognizes 10.12 as a valid deployment target and just falls back to 14.2, which is too new for our CI.
…iftlang#4872) From Clang 15, nested static initializer inside statement-expression is no longer a constant-time expression (See https://reviews.llvm.org/D127201). OSS Foundation defines `CFSTR` as a macro rather than `__builtin___CFStringMakeConstantString` and it uses nested static initializer inside statement-expression, so we can't assume `CFSTR` itself is always a constant-time expression. This patch removes some `static` qualifiers associated with `CFSTR` to make them acceptable with Clang 15 and later.
…5-min-macos Bump the macOS deployment target to 10.13 in the Xcode project.
CG types are sendable
…name-sendable NSNotification.Name is sendable
…09a1be99a234eb27e067d15e44dbf [wasm][build] Guard libdispatch and Threads usage with HAS_LIBDISPATCH_API
This is a follow up to 5e7281b, which just adds the `BUILD_TOOLS` option but doesn't actually use it. This patch renames the option to follow the CMake conventions and uses it to actually exclude the tools from the build.
This change ports the thread-related APIs for the no thread platform by adding no-op implementations. Note that WASI is going to support threads in the near future, so this does not guard by `TARGET_OS_WASI` but by `!SWIFT_CORELIBS_FOUNDATION_HAS_THREADS` to make it easier for future WASI + threads support.
…4e4dfb622a01da59752a0bf3f863a [wasm] Port BlocksRuntime for no dlfcn.h platforms
This lets us override the library subdir name when its derivation isn't straightforwardly just the lower-case version of `CMAKE_SYSTEM_NAME`. rdar://123381867
This is needed when we're statically linking, otherwise we can't pull in Dispatch because we won't have RT::rt as a CMake target. rdar://123381867
Musl doesn't have fts built-in; it's in a separate library, which we need to add if we're going to use it. rdar://123381867
…4043fc1aba1eaa9209ac85b3f9c85 [wasm][build] Handle `FOUNDATION_BUILD_TOOLS` value set to `OFF`
* Remove no longer needed `#if !TARGET_OS_WASI` * Add WASI to the list of ICU supported platforms
This patch guards the use of RunLoop, which is not available on no-dispatch platforms.
* Remove no longer needed `#if !TARGET_OS_WASI` * Add WASI to the list of ICU supported platforms
…f2e3c7c9dbac72190d1b8f6fd3450 [wasm] Grab wasi-libc constants manually
…116072901095068b9a6ebcd87097f [wasm] Guard out the use of `libdispatch` types
…db6b3c22f9cf4b0462b78b9ad200f [wasm] Port CoreFoundation/NumberDate.subproj
…1c67a4ca921c850b81d5c9dd2a517 [wasm] Port CoreFoundation/Locale.subproj
…79df6e55adf8d4486ed2e4245b6ab [wasm] Port CFStream for no-dispatch platforms
…da48de18bce17b4ed1f33afc48610 [wasm] Port CoreFoundation/Parsing.subproj
* CFXMLInterface usually depends on BlocksRuntime through dispatch indirectly, so we need to link it explicitly for no-dispatch builds to include BlocksRuntime headers. * Enable some wasi-libc emulations for building CF.
…ee42afb2f55776bf64ea23359ad95 [wasm] Port CoreFoundation/CMakeLists.txt
…067e20476f1b3341e8c8c599542e9 [wasm] Guard RunLoop.subproj sources with `__HAS_DISPATCH__`
This change enables wasi-libc emulations for Foundation and FoundationXML to properly import CoreFoundation, which includes those emulation libraries as a part of public interface.
* Unsupport background read/write operations * Unsupport Pipe
* Removed too conservative guards * Port `Host` class * Add `arch(wasm32)` to 32-bit arch conditions
Importing `wasi_emulated_mman` in Swift code requires the client to define `_WASI_EMULATED_MMAN`. `@_implementationOnly import` was the only way to work around this, but it's now declared as unsafe if it's used in non-resilient moules (even though it's actually safe as long as the module does not use type layout of the imported module). The new scoped import feature always requires the transitive clients to load privately imported modules, so it's not a good fit for this tricky case where a special macro must be defined before importing the module. This patch imports `sys/mman.h` through CoreFoundation while defining `_WASI_EMULATED_MMAN` in the header exposed by modulemap. This way, the clients don't need to define it.
…bb96680c2c10a64f35b9d4b23b71c [wasm] Enable wasi-libc emulations for Foundation
…057fdae9a44e9299afba97392ce2d
…f87833bc2dd02699cb74458b0b830
…08c010f2f537a9c35fc2a364e1b1c
* Remove too conservative include guards * Update class table to exclude unavailable classes * Port mach_absolute_time to WASI platform
This patch is a follow-up fix for efc0182 to fix undefined symbol reference against excluded CFRunLoop APIs.
…0575216a3850e34deeea997cb248d [wasm] Exclude some completely unavailable APIs from build
…c29bd10a48d6700a55e6668a839ca [wasm] Port Sources/Foundation/NSObjCRuntime.swift
…c1adfac08b4827338f7279ed6f11f [wasm] Miscellanous Base.subproj fixes
…c1791d383721519556d1d8de3d6fb [wasm] Follow-up dispatch fix for CFStream.c
…bd084677297a09372a39cbf105765
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]
Can you help keep this open source service alive? 💖 Please sponsor : )