This change adds a new type of cache (cache by type descriptor) to the protocol conformance lookup system. This optimization is beneficial for generic types, where the
same conformance can be reused across different instantiations of the generic type.
Key changes:
- Add a `GetOrInsertManyScope` class to `ConcurrentReadableHashMap` for performing
multiple insertions under a single lock
- Add type descriptor-based caching for protocol conformances
- Add environment variables for controlling and debugging the conformance cache
- Add tests to verify the behavior of the conformance cache
- Fix for https://github.com/swiftlang/swift/issues/82889
The implementation is controlled by the `SWIFT_DEBUG_ENABLE_CACHE_PROTOCOL_CONFORMANCES_BY_TYPE_DESCRIPTOR`
environment variable, which is enabled by default.
When the concurrency library's "is current global actor" hook is not
available, assume that we are already executing on the right global
actor. This mimics the behavior of earlier standard libraries when
faced with an isolated conformance, as well as dealing with odd
configurations where the code might not load the concurrency library
yet
At the moment, WebAssembly ends up in this configuration because we
don't run the initialization for the concurrency library. That makes
this also a workaround for issue #82682 / rdar://154762027.
Musl's `clone()` wrapper returns `EINVAL` if you try to use `CLONE_THREAD`,
which seems a bit wrong (certainly it is in this particular application,
since we *really* don't care whether the thread is a valid C library
thread at this point).
Also properly support ELF images that are built with a base address other
than zero (this typically isn't an issue for dynamically linked programs,
as they will be relocated at runtime anyway, but for statically linked
binaries it's very common to set the base address to a non-zero value).
rdar://154282813
When ObjC interop is not available, Error values are represented in ErrorObject boxes. These are full HeapObjects, but unowned refcounting ops asserted that the metadata was class metadata. This assert would be hit when destroying an ErrorObject that was weakly referenced. Expand the asserts to accept ErrorObject metadata as well.
rdar://150214921
We had fixed this bug in https://github.com/swiftlang/swift/pull/79381
but missed to realize the same problem existed for parameters as well.
This corrects the swift_func_getParameterTypeInfo impl, and also removes
the entire "unsafe" method, we no longer use it anywhere.
Resolves rdar://146679254
The "was already deallocated" message is incorrect, since the target of an unowned reference stays allocated even after being deinitialized. We could say "was already deinitialized" but that's a bit of a niche term. "Was already destroyed" conveys what happened without the reader needing to worry about deinitialization versus deallocation.
rdar://149237704
The new build system set `SWIFT_RUNTIME_CLOBBER_FREED_OBJECTS` to 0.
Unfortunately, the check in the Swift runtime used `#ifdef`, so even
though it was turned off, it was actually enabled in some cases.
Fixing the issue in the build system as well as switching the check to
verify that value of `SWIFT_RUNTIME_CLOBBER_FREED_OBJECTS` is taken into
account in the sources. C/C++ implicitly defines macro values to 1 when
set without a value and 0 when it is not set.
Also making the hex a bit more recognizable and grep'able by including
it as a comment.
Fixes: rdar://149210738
This memory is part of the conformance cache concurrent hash map, so
when we clear the conformance cache, record each of the allocated
pointers within the concurrent map's free list. This way, it'll be
freed with the rest of the concurrent map when it's safe to do so.
With relative witness tables, the low bit of a witness table pointer is
an indicator that we need to load from the given pointer. We were also
using the low bit of the witness table pointer in the conformance
cache entry as part of a pointer union. Hilarity ensures [*].
Switch to another low bit by exploding the conformance cache key
into separate fields and taking the low bit of one of those pointers
that isn't reserved.
Fixes the remainder of rdar://149326058, I hope.
[*] No, I am not laughing.
The metadata creation system detects cycles where metadata depends on other metadata which depends on the first one again and raises a fatal error if the cycle can't be fulfilled.
Some cycles can be fulfilled. The cycle may involve a requirement for a metadata state less than full transitive completeness which can be reached without resolving the entire cycle. We only want to raise a fatal error when we detect a cycle that can't be fulfilled.
Normally this happens because the cycle checking in `blockOnMetadataDependency` only sees a cycle when it can't be fulfilled. Metadata initialization is advanced as far as it can be at each stage, so a cycle that can be fulfilled will see a fulfilling state and won't generate the dependency in the first place, since we only generate dependencies that haven't yet been met.
However, when two threads race to create types in a cycle, we can end up with such a dependency, because the dependency may be generated before another thread fulfilled yet. The cycle checker doesn't account for this and incorrectly raises a fatal error in that case.
Fix this by checking the cyclic dependency against the metadata's current state. If we have a dependency that's already been fulfilled, then there isn't really a dependency cycle. In that case, don't raise a fatal error.
rdar://135036243
To facilitate back deployment, make use of the fact that the async bit
has up to now never been set for read and modify accessors and claim
that set bit to indicate that it is a callee-allocated coroutine. This
has the virtue of being completely back deployable because like async
function pointers coro function pointers must be auth'd and signed as
data.
Remove Malloc Type Descriptor cache and trivialize
`computeMallocTypeSummary()` to only provide
language. The remaining info in
`malloc_type_summary_t` are currently not used by
the allocator.
The principled, long-term solution is to have the
Swift compiler compute type descriptors for Swift
types.
rdar://137993434
Certain dynamic casts cannot work safely with isolated conformances,
regardless of what executor the code runs on. For such cases, reject
all attempts to conform to the type.
Replace this direct use of the count in a table header as the upper
bound of a for loop with a range-based for loop over the range which was
being indexed into. That range was constructed using that count to
begin with.
Rather than pass a MethodOverrideDescriptor directly, instead pass the
fields from it that are needed by the callee. In preparation for adding
another caller which doesn't have a MethodOverrideDescriptor.
This replaces `strdup` with `_strdup` on Windows to avoid the POSIX API
deprecation warnings. It also does a minor simplification by removing
the superfluous `else`.
We have a few constructor functions that aren't wrapped in SWIFT_ALLOWED_RUNTIME_GLOBAL_CTOR_BEGIN/SWIFT_ALLOWED_RUNTIME_GLOBAL_CTOR_END and which have started to produce warnings in a new clang version. Explicitly allow these constructors by adding those.
rdar://147703947
This fixes a `copy constructor must pass its first argument by reference` compilation error when compiled with a recent enough Clang (after fe0d3e3764)
* [CS] Decline to handle InlineArray in shrink
Previously we would try the contextual type `(<int>, <element>)`,
which is wrong. Given we want to eliminate shrink, let's just bail.
* [Sema] Sink `ValueMatchVisitor` into `applyUnboundGenericArguments`
Make sure it's called for sugar code paths too. Also let's just always
run it since it should be a pretty cheap check.
* [Sema] Diagnose passing integer to non-integer type parameter
This was previously missed, though would have been diagnosed later
as a requirement failure.
* [Parse] Split up `canParseType`
While here, address the FIXME in `canParseTypeSimpleOrComposition`
and only check to see if we can parse a type-simple, including
`each`, `some`, and `any` for better recovery.
* Introduce type sugar for InlineArray
Parse e.g `[3 x Int]` as type sugar for InlineArray. Gated behind
an experimental feature flag for now.
It's hard to tell why a crash occurred with just "Could not allocate memory." Modify the message to include the size/alignment, which will help distinguish between an actual lack of memory and a request for an excessively large allocation.
While we're in there, add \n to a bunch of other fatal error helper functions that didn't have it.
* [Concurrency] Detect non-default impls of isIsolatingCurrentContext
* [Concurrency] No need for trailing info about isIsolating... in conformance
* Apply changes from review
