Per the code comment, stdint.h is provided by clang and therefore
conflicts with Glibc; additionally, clang defines some particular
type macros for making the appropriate `typedef`s.
OpenBSD uses clang-10, so we can also use these types on this platform.
This also addresses a test case that has gone awry.
This patch has two desirable effects for the price of one.
1. An uncaught error thrown from main will now explode
2. Move us off of using runAsyncAndBlock
The issue with runAsyncAndBlock is that it blocks the main thread
outright. UI and the main actor need to run on the main thread or bad
things happen, so blocking the main thread results in a bad day for
them.
Instead, we're using CFRunLoopRun to run the core-foundation run loop on
the main thread, or, dispatch_main if CFRunLoopRun isn't available.
The issue with just using dispatch_main is that it doesn't actually
guarantee that it will run the tasks on the main thread either, just
that it clears the main queue. We don't want to require everything that
uses concurrency to have to include CoreFoundation either, but dispatch
is already required, which supplies dispatch_main, which just empties
out the main queue.
In the new clang, this declaration ends up influencing the redeclaration chain, altering the nullability of the `free(_:)` function imported into Swift.
Fixes rdar://71269128. Note that tests may fail unless a clean build is performed.
Because the shims are generally meant for the standard library build,
which requires clang, we can default to using the compiler vended
information for the types.
When building for Windows x86, we have a few conspiring issues to
contend with. `__builtin_sqrtf` is treated by clang as a `__builtin_`
prefixed libm call. On windows, there is no libm, with the role being
taken up by ucrt. However, on 32-bit x86 targets, ucrt does not provide
an implementation of `sqrtf` instead defining it inline as a wrapper
which widens the argument to a double precision and invokes `sqrt`, the
result of which is narrowed to the result. This function is locally
defined and expected to be inlined and no out-of-line definition is
provided by ucrt that can be referenced.
Adjusting the shims to use the intrinsics would be the next option
(thanks @stephentyrone!) which would work. However, when building the
standard library, we need to combine the system headers which results in
the use of the MSVCRT headers for `xmmintrin.h` rather than clang. As a
result, we cannot directly use the intrinsics.
Opt to instead open-code the intrinsic path by using the compiler
builtin for sqrt. This both yields the optimal implementation and
avoids providing an additional entry point in the runtime. It also has
code size benefits.
A special thanks to @stephentyrone for all the discussion and help with
this!
In derivatives of loops, no longer allocate boxes for indirect case payloads. Instead, use a custom pullback context in the runtime which contains a bump-pointer allocator.
When a function contains a differentiated loop, the closure context is a `Builtin.NativeObject`, which contains a `swift::AutoDiffLinearMapContext` and a tail-allocated top-level linear map struct (which represents the linear map struct that was previously directly partial-applied into the pullback). In branching trace enums, the payloads of previously indirect cases will be allocated by `swift::AutoDiffLinearMapContext::allocate` and stored as a `Builtin.RawPointer`.
While the existing _forEachField in ReflectionMirror.swift
already gives the offsets and types for each field, this isn't
enough information to construct a keypath for that field in
order to modify it.
For reference, this should be sufficent to implement the features
described here: (https://forums.swift.org/t/storedpropertyiterable/19218/62)
purely at runtime without any derived conformances for many types.
Note: Since there isn't enough reflection information for
`.mutatingGetSet` fields, this means that we're not able to support
reflecting certain types of fields (functions, nonfinal class fields,
etc). Whether this is an error or not is controlled by the `.ignoreUnknown`
option.
Previously, overflow and underflow both caused this to return `nil`, which causes several problems:
* It does not distinguish between a large but valid input and a malformed input. `Float("3.402824e+38")` is perfectly well-formed but returns nil
* It differs from how the compiler handles literals. As a result, `Float(3.402824e+38)` is very different from `Float("3.402824e+38")`
* It's inconsistent with Foundation Scanner()
* It's inconsistent with other programming languages
This is exactly the same as #25313
Fixes rdar://problem/36990878
There are things about this that I'm far from sold on. In
particular, I'm concerned that in order to implement escalation
correctly, we're going to have to add a status record for the
fact that the task is being executed, which means we're going
to have to potentially wait to acquire the status lock; overall,
that means making an extra runtime function call and doing some
atomics whenever we resume or suspend a task, which is an
uncomfortable amount of overhead.
The testing here is pretty grossly inadequate, but I wanted to
lay down the groundwork here.
This is not an ideal solution, as we are likely installing more that we
should with those instructions -- but it would unblock quickly the
Source Compatibility suite.
Addresses rdar://70040046
The bare "PATTERN" argument by default does nothing, you need either
"EXCLUDE" or "FILES_MATCHING" to make it do something. This likely
wasn't previously a problem because clang is only installing headers,
but it should be fixed for robustness.
- deduplicate the logic to compute the resource folder
- install headers and module files in shared and static resource folders
- forward -static flag when calling swiftc with -print-target-info
The experimental concurrency model will require a supporting runtime
and possibly end-user-visible library constructs. Introduce a stub of
such a library, enabled by a new `build-script` option
`--enable-experimental-concurrency`, so we have a place to put this
work.
Most SwiftShims were put in the swift namespace in C++ mode which broke certain things when importing them in a swift file in C++ mode. This was OK when they were only imported as part of the swift runtime but, now they are used in C++ mode both in the swift runtime and when C++ interop is enabled.
This broke when C++ interop was enabled because the `Swift` module contains references to symbols in the SwiftShims headers which are built without C++ interop enabled (no "swift" namespace). But, when C++ interop is enabled, the SwiftShims headers would put everything in the swift namespace meaning the symbols couldn't be found in the global namespace. Then, the compiler would error when trying to deserialize the Swift module.
Move the ObjC class name stability check logic to the Swift runtime, exposing it as a new SPI called _swift_isObjCTypeNameSerializable.
Update the reporting logic. The ObjC names of generic classes are considered stable now, but private classes and classes defined in function bodies or other anonymous contexts are unstable by design.
On the overlay side, rewrite the check’s implementation in Swift and considerably simplify it.
rdar://57809977
However, when building Glibc with assertions enabled, LLVM asserts in
CodeGenModule::EmitGlobal with "Cannot emit local var decl as global".
This assert is _probably_ wrong in LLVM because the local extern
reference isn't being handled properly and needs to be addressed there.
We could move the declaration to global scope, but that is not ideal
because it makes the pointer declaration visible to Swift.
OpenBSD needs to implement _swift_stdlib_getEnviron regardless, so
let's do so.
In an assert built of the library, store an extra boolean flag (isImmutable) in the object side-buffer table.
This flag can be set and get by the Array implementation to sanity check the immutability status of the buffer object.
This reduces the dependency on `LLVMSupport`. This is the first step
towards helping move towards a local fork of the LLVM ADT to ensure that
static linking of the Swift runtime and core library does not result in
ODR violations.
This replaces `LLVM_LIBRARY_VISIBILITY` with `SWIFT_LIBRARY_VISIBILTIY`
througout the runtime. The purpose of this attribution is unclear -
building with `-fvisibility=hidden` would accomplish this. This is an
entirely mechanical change replacing the macro with the Swift namespaced
variant instead.
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.
This removes the GNUC version check as the runtime does require ABI
support which is not present in GCC. Remove the unnecessary check and
simplify the condition by checking the file format that the visibility
attribute is being applied to and limit it to the ones supporting it.
The current version of the Foundation overlay doesn’t use these, but we should still keep them in case a toolchain snapshot build picks up on overlay module from one of the SDKs in Xcode 11.
rdar://62339802
malloc introspection is a platform feature that is unavailable on
OpenBSD. There is no workaround for the feature, so we have to assume
that allocations succeed in allocating exactly the amount of memory
requested, and nothing more.
Here a new mallocSize shim is introduced so the feature check for malloc
introspection is pushed to the shims, rather than using os checks
directly from Swift. Not every use of malloc_size has been converted
yet; ManagedBuffer.swift still remains. However, this module requires
special care to fix, which will be done separately.
This reverts commit 5fd6e98b2f, reversing
changes made to 3aee49d9d0.
Revert "XFAIL test/Interpreter/metadata_access.swift on arm64e"
This reverts commit 8fe216b004.
Revert "XFAIl test on os stdlib bots"
This reverts commit aea5fa4842.
