Merge main 2022-06-11 #4641
Merged
Merge main 2022-06-11 #4641
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
This iteration ranged from `buffer.startIndex` to `buffer.count`, rather than to `buffer.endIndex`. Using `buffer.indices` is a better solution in any case.
SWIFT_STDLIB_SINGLE_THREADED_RUNTIME is too much of a blunt instrument here. It covers both the Concurrency runtime and the rest of the runtime, but we'd like to be able to have e.g. a single-threaded Concurrency runtime while the rest of the runtime is still thread safe (for instance). So: rename it to SWIFT_STDLIB_SINGLE_THREADED_CONCURRENCY and make it just control the Concurrency runtime, then add a SWIFT_STDLIB_THREADING_PACKAGE setting at the CMake/build-script level, which defines SWIFT_STDLIB_THREADING_xxx where xxx depends on the chosen threading package. This is especially useful on systems where there may be a choice of threading package that you could use. rdar://90776105
Read/write locks are not as good as you'd think; a simple mutex is better in almost all cases. rdar://90776105
Moved all the threading code to one place. Added explicit support for Darwin, Linux, Pthreads, C11 threads and Win32 threads, including new implementations of Once for Linux, Pthreads, C11 and Win32. rdar://90776105
The threading unit tests currently just check the operation of Mutex. This used to be part of the runtime tests, but now it's a separate library we can test it separately. rdar://90776105
Added explicit tests for `swift::once` and also for the ulock implementation used on Linux. rdar://90776105
The file is called Nothreads.cpp, not NoThreads.cpp. rdar://90776105
Some things (LLDB's language plugin, for instance), include Swift headers from outside of our build system, and may not know to define one of the threading package defines. rdar://90776105
Some declarations were missing from non-Darwin sources, and the Linux header was slightly broken. rdar://90776105
A few fixes specifically for the Linux build. rdar://90776105
We want this initialized when we decide which threading package to use. This isn't a problem on Darwin or Linux where we're using the build script, but on Windows it relies on the defaulting mechanism, which didn't happen until further down the `CMakeLists.txt`. rdar://90776105
When we static link against libswiftCore, we need it to contain the actual object modules from the threading library (when it's dynamically linked, the shared object will already contain those modules because it's been linked against libswiftThreading), which means that the threading library in the stdlib needs to be an OBJECT_LIBRARY rather than a STATIC library (otherwise people will have to statically link against the threading library as well, and that'll need to be installed, and we don't want that). rdar://90776105
I'd renamed the setting, but failed to update build-presets.ini. rdar://90776105
Apparently I missed a close brace from the end of Win32.h. rdar://90776105
Looks like I forgot to update the Win32.h implementation. rdar://90776105
rdar://90776105
`windows.h` defines a couple of very unhelpfully named macros. Undefine them after including it. rdar://90776105
We're using some functions from Synchronization.lib now, after the threading changes. rdar://90776105
We can't safely include <windows.h> because it defines a large number of macros, some of which clash with things in the Swift source tree, and others of which clash with things in the LLVM source tree. Sadly we *also* can't just include the Windows headers we need, because they pull in some of the problematic macros. In this instance, the best thing seems to be to grab the definitions for the types and functions we are going to use and put them in their own header file. If we define them correctly, then #including <windows.h> before or after this header won't have any adverse effects. rdar://90776105
We shouldn't include <windows.h> implicitly from .cpp files, but should do it directly so that we know it's there. Also, if we're including <windows.h>, do it at the top of the file. rdar://90776105
The concurrency library can use the new threading library functions, which avoids the problem of including <windows.h>. rdar://90776105
Declaring _RTL_SRWLOCK ourselves causes clashes with <windows.h>. Rather than doing that, declare an equivalent struct, and some overloads. rdar://90776105
Actor.cpp does need <io.h> still, and Task.cpp should have been including <windows.h> rdar://90776105
TaskLocal.cpp doesn't need <handleapi.h> or <processthreadsapi.h>, both of which want <windows.h>, which isn't included any more. rdar://90776105
We need to link the threading unit test against Synchronization.lib to pick up the Win32 APIs we're using. rdar://90776105
The runtime unit tests also need to link with Synchronization.lib. rdar://90776105
[doc] mention `loadUnaligned` in the description of `UnsafeRawBufferPointer`
[stdlib] fix an indexing inconsistency
…ntialinit-rdar94369218 [CodeCompletion] Don't suggest initializers on existential types
`swift::once` needs to be 32-bit on 32-bit Linux, which means we have to revert to using a global lock. rdar://94831034
…onFailure-docs [docs] improvements for assertionFailure and preconditionFailure
…uire-recent-swift [SwiftCompilerSources] Require very recent Swift compiler in `HOSTTOOLS` mode
…ft-string-init Revert "Revert "[cxx-interop][SwiftCompilerSources] Fix conversion between `std::string` and `Swift.String`""
…1c791eb80e78022f940f91e [move-only] Add copyable_to_moveonlywrapper and moveonlywrapper_to_copyable instructions.
Correct complexity statement for Sequence compactMap
This reverts commit bcb86b2. For some reason this isn't working, need to investigate.
[ToolingLibs] Build tooling libs with libswift
… in concretizeNestedTypesFromConcreteParent() We can't just ignore unavailable conformances because the generic signature we're computing might itself be attached to an unavailable declaration. Until we get a proper fix, only drop unavailable conformances to Sendable here. Fixes rdar://problem/94305457.
…ose-async-and-transparent-func [cxx-interop] Don't expose async or @_alwaysEmitIntoClient functions
…n_num_threads IRGen: Add a frontend option to force single LLVM module emission in multithreaded mode
…12a964188317a060ae17d89 [SIL.rst] Fix two rst errors to fix the build.
…onformance-fix RequirementMachine: Fix handling of unavailable Sendable conformances in concretizeNestedTypesFromConcreteParent()
Remove a FIXME from validation-test/stdlib/FixedPoint.swift.gyb
[Threading] Fix 32-bit Linux.
…06-11 Conflicts: cmake/caches/Runtime-WASI-wasm32.cmake include/swift/Runtime/ThreadLocalStorage.h stdlib/public/Concurrency/AsyncStream.cpp stdlib/public/runtime/RuntimeInvocationsTracking.cpp stdlib/public/stubs/ThreadLocalStorage.cpp
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.
No description provided.