This replaces a number of `#include`-s like this:
```
#include "../../../stdlib/public/SwiftShims/Visibility.h"
```
with this:
```
#include "swift/shims/Visibility.h"
```
This is needed to allow SwiftCompilerSources to use C++ headers which include SwiftShims headers. Currently trying to do that results in errors:
```
swift/swift/include/swift/Demangling/../../../stdlib/public/SwiftShims/module.modulemap:1:8: error: redefinition of module 'SwiftShims'
module SwiftShims {
^
Builds.noindex/swift/swift/bootstrapping0/lib/swift/shims/module.modulemap:1:8: note: previously defined here
module SwiftShims {
^
```
This happens because the headers in both the source dir and the build dir refer to SwiftShims headers by relative path, and both the source root and the build root contain SwiftShims headers (which are equivalent, but since they are located in different dirs, Clang treats them as different modules).
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
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 code that saves/restores the exclusivity checks for tasks was
newly introduced into the runtime. Clone that code into the back-
deployed version of the runtime.
Some notes:
1. Even though I refactored out AccessSet/Access from Exclusivity.cpp ->
ExclusivityPrivate.h, I left the actual implementations of insert/remove in
Exclusivity.cpp to allow for the most aggressive optimization for use in
Exclusivity.cpp without exposing a bunch of internal details to other parts of
the runtime. Smaller routines like getHead() and manipulating the linked list
directly I left as methods that can be used by other parts of the runtime. I am
going to use these methods to enable backwards deployment of exclusivity support
for concurrency.
2. I moved function replacements out of the Exclusivity header/cpp files since
it has nothing to do with Exclusivity beyond taking advantage of the TLS context
that we are already using.
The specific environment variable is SWIFT_DEBUG_RUNTIME_EXCLUSIVITY_LOGGING. We only
check the environment the first time we try to lookup the TLSContext, so it
shouldn't impact exclusivity performance.
My intention is to use this to write some FileCheck tests so that we can really
be sure that the runtime is doing what we think it is. As such I also changed
the small amount of logging routines meant for use in the debugger to use stdout.
The implemented semantics are that:
1. Tasks have separate exclusivity access sets.
2. Any synchronous context that creates tasks will have its exclusive access set
merged into the Tasks while the Task is running.
rdar://80492364
I ran into this while implementing
async actor inits; where I was emitting
an actor hop in the middle of
an access region, which caused the
access set to be unexpectedly empty.
This removes the LLVMSupport usage for thread local. This effectively
is a no-op as the runtime requires that it is built with clang, which
provides the C++11 `thread_local` support on all the targets. In the
case that the target does not support `thread_local`, clang would
fallback to `__declspec(thread)` on MSVC and `__thread` on other modes.
However, because the runtime is always built in C++14 mode, the
`thread_local` support should be assumed to be present. Remove the
unnecessary condition and inline the single use of the macro for
`thread_local`.
This replaces the `LLVM_ATTRIBUTE_ALWAYS_INLINE` with `SWIFT_INLINE`
which is equivalent but namespaced to Swift instead. This reduces the
unnecessary reliance on LLVMSupport.
Instead of a thunk insert the dispatch into the original function.
If the original function should be executed the prolog just jumps to the "real" code in the function. Otherwise the replacement function is called.
There is one little complication here: when the replacement function calls the original function, the original function should not dispatch to the replacement again.
To pass this information, we use a flag in thread local storage.
The setting and reading of the flag is done in two new runtime functions.
rdar://problem/51043781
Remove the compiler support for exclusivity warnings.
Leave runtime support for exclusivity warnings in non-release builds
only for unit testing convenience.
Remove a test case that checked the warning log output.
Modify test cases that relied on successful compilation in the
presence of exclusivity violations.
Fixes: <rdar://problem/45146046> Remaining -swift-version 3 tests for exclusivity
Use AccessedStorageAnalysis to find access markers with no nested conflicts.
This optimization analyzes the scope of each access to determine
whether it contains a potentially conflicting access. If not, then it
can be demoted to an instantaneous check, which still catches
conflicts on any enclosing outer scope.
This removes up to half of the runtime calls associated with
exclusivity checking.
There are multiple reasons to do this. Primarily this is
useful as an optimization. Whenever analysis can determine that no
potentially conflicting access occurs within the scope, the access can
be demoted to "nontracking". It is also useful as an escape hatch for
future code deploying to older runtimes. For example, if a future access
scope may cross threads, and the older runtime doesn't know how to
migrate threads.
See <rdar://problem/37507434> add a flag to swift_beginAccess to inform
the runtime that an access might migrate between threads
32-bit iOS 9 simulator and 32-bit watchOS 2 simulator do not support
C++ thread_local, even though clang's has_feature(cxx_thread_local)
thinks they do.
rdar://35063043
This is a smorgasbord of warning cleanups in the runtime. This just
adjusts the casts for the various types. There were a number of casts
which lost const qualifiers on the type.
* Extend Swift runtime issue reporting for @objc inference to include details about the declaration of the method (that is missing the @objc annotation) and a suggested fix-it. This changes the ABI of RuntimeErrorDetails, so we're also bumping the version.
* Update SwiftObject.mm
* Implements a debugger hook (breakpoint) API and data structure. This structure is passed to the debugger and describes extra information about a fatal error or a non-fatal warning, which should be logged as a runtime issue.
This debugger hook is then used from two places, which currently only log to stderr:
- Runtime exclusivity violations.
- Swift 3 implicit Obj-C entrypoints.
A subsequent LLDB support will be able to catch these callbacks and show the runtime issues in a better way than just logging them to stderr. When the debugger is not attached, this shouldn't have any effect.
