On all platforms except Linux, calling `withLockIfAvailable()`
recursively just returns `nil`. However, our Linux implementation
chooses to abort the process instead. We don't need this
inconsistent/destructive behaviour and can just return `nil` as we do
elsewhere.
In https://github.com/swiftlang/swift/pull/84792 we have added
implementation to `Equatable` and `Hashable` there are two issues with
this.
1. Uses of type `GUID` would be emitted in the `swiftinterface` file as
`_GUIDDef._GUID` since it is an external type. but the type name in the
imported header file is `GUID` and not `_GUID`
2. When compiling using `-cxx-interoperability-mode=default`, there are
duplicate definition errors for `==` since the c++ header file defines
the same operator.
Proposed changes:
1. Add a type alias `typealias _GUID = GUID` to address the naming
mismatch in the generated interface file
2. Add conditional definitions of the equatable implementation to avoid
duplicate definitions.
---------
Co-authored-by: Jonathan Grynspan <grynspan@me.com>
The write back creates a false dependency between the first and subsequent stores when creating
and the last load and subsequent ops when destroying a stack frame.
Instead of copying the data and the type and witnesses separately, use the size in the value witness table and copy everything at once.
copyTypeInto assumed the type was an ordinary existential. When it was actually an extended existential, it would do an incorrect cast and read part of a pointer as the number of witness tables to copy. This would typically result in a large buffer overflow and crash. At this point we already know the type's size, so we can use that info directly rather than essentially recomputing it.
rdar://163980446
Add SWIFT_DEBUG_ENABLE_TASK_SLAB_ALLOCATOR, which is on by default. When turned off, async stack allocations call through to malloc/free. This allows memory debugging tools to be used on async stack allocations.
This adds initial support for differentiation of functions that may produce `Error` result.
Essentially we wrap the pullback into `Optional` and emit a diamond-shape control flow pattern depending on whether the pullback value is available or not. VJP emission was modified to accommodate for this. In addition to this, some additional tricks are required as `try_apply` result is not available in the instruction parent block, it is available in normal successor basic block.
As a result we can now:
- differentiate an active `try_apply` result (that would be produced from `do ... try .. catch` constructions)
- `try_apply` when error result is unreachable (usually `try!` and similar source code constructs)
- Support (some) throwing functions with builtin differentiation operators. stdlib change will follow. Though we cannot support typed throws here (yet)
- Correctly propagate error types during currying around differentiable functions as well as type-checking for `@derivative(of:)` attribute, so we can register custom derivatives for functions producing error result
- Added custom derivative for `Optional.??` operator (note that support here is not yet complete as we cannot differentiate through autoclosures, so `x ?? y` works only if `y` is not active, e.g. a constant value).
Some fixes here and there
Complex equality is encoded in the low bit of the witness table pointer. We need to mask off the low bits when bitcasting to an `any SerialExecutor`.
rdar://164005854
Fix crash when creating a Span from an empty InlineArray whose storage
is only byte-aligned. #85265.
---------
Co-authored-by: Guillaume Lessard <glessard@tffenterprises.com>
Inspired by #84826, I've dusted off and completely reworked a native
implementation of integer-to-string conversion.
Besides existing tests in this repository, the core of the
implementation has been comprehensively tested in a separate package for
all bases between 2–36 to demonstrate identical output for all 8-bit and
16-bit values, and for randomly generated 32-bit, 64-bit, and 128-bit
values.
Resolves#51902.
<!--
If this pull request is targeting a release branch, please fill out the
following form:
https://github.com/swiftlang/.github/blob/main/PULL_REQUEST_TEMPLATE/release.md?plain=1
Otherwise, replace this comment with a description of your changes and
rationale. Provide links to external references/discussions if
appropriate.
If this pull request resolves any GitHub issues, link them like so:
Resolves <link to issue>, resolves <link to another issue>.
For more information about linking a pull request to an issue, see:
https://docs.github.com/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
-->
<!--
Before merging this pull request, you must run the Swift continuous
integration tests.
For information about triggering CI builds via @swift-ci, see:
https://github.com/apple/swift/blob/main/docs/ContinuousIntegration.md#swift-ci
Thank you for your contribution to Swift!
-->
functions.
These were introduced in an early draft implementation of async let, but
never used by a released compiler. They are not used as symbols by any
app binaries. There's no reason to keep carrying them.
While I'm at it, dramatically improve the documentation of the remaining
async let API functions.
This nudges the Glibc modulemap just enough to get SwiftPM and later
targets building. Without it, Swift tries to import the signal hander
APIs through CDispatch instead of Glibc. CDispatch shouldn't be directly
imported, so recommending that is nonsensical.
This is not a full solution for all headers, but meant to perturb the
module machinery sufficiently that it pulls signal.h into glibc
correctly.
Works around:
```
Swift-Project/swiftpm/Sources/Basics/Cancellator.swift:79:24:
error: property '__sigaction_u' is not available due to missing import of defining module 'CDispatch' [#MemberImportVisibility]
```
Instead of using weak definitions of swift_retain_preservemost and swift_release_preservemost, use weak references and explicitly check them for NULL.
Embedded Swift uses weak definitions for its runtime symbols. If swiftCore is able to override the weak definitions of the _preservemost functions, it will also override the Embedded symbols. They are not compatible, so this ends poorly.
This is breaking embedded due to its use of weak definitions for embedded versions of the runtime functions. The presence of a weak export in libswiftCore allows any strong symbol in libswiftCore to override a weak symbol elsewhere. Remove while we work out how to reconcile the two.
rdar://163578646
Item::destroy will call free when there's no task, so the allocation needs to match, lest we free something that wasn't malloced and crash.
rdar://162589711
`pthread_mutex_trylock` return `0` on success.
```
NAME
pthread_mutex_trylock – attempt to lock a mutex without blocking
SYNOPSIS
#include <pthread.h>
int
pthread_mutex_trylock(pthread_mutex_t *mutex);
DESCRIPTION
The pthread_mutex_trylock() function locks mutex. If the mutex is already locked,
pthread_mutex_trylock() will not block waiting for the mutex, but will return an error
condition.
RETURN VALUES
If successful, pthread_mutex_trylock() will return zero, otherwise an error number will
be returned to indicate the error.
ERRORS
The pthread_mutex_trylock() function will fail if:
[EINVAL] The value specified by mutex is invalid.
[EBUSY] Mutex is already locked.
```