Memory analysis tools have trouble identifying the metadata allocator pages. When allocating a new page, write a pointer to the previous page at the end. Combined with the existing _swift_debug_allocationPoolPointer variable, this will allow all metadata allocation pages to be identified definitively.
rdar://175515505
Add an environment variable that makes swift_getCanonicalSpecializedMetadata ignore noncanonical specialized metadata, for testing runtime-instantiated metadata.
The VWT flags for isNonCopyable aren't always being set
correctly by the runtime when it is creating type metadata.
We can't always set them correctly, in the case of fixed-layout
types, as their VWT is static and read-only, yet could still be
conditionally copyable. For example:
```
struct FactoryOf<T: ~Copyable>: ~Copyable {
var counter: Int = 0
}
extension FactoryOf: Copyable where T: Copyable {}
```
In the common case of an unconditionally Copyable type, we do
effectively two quick bit-tests: one to see if the VWT thinks
it "could be Copyable" and then delegate to
`checkInvertibleRequirements` which has a fast-path for types
that are unconditionally Copyable by checking some bits in the
type's context descriptor.
related to rdar://176282041
Replace the boolean SWIFT_DEBUG_ENABLE_MALLOC_SCRIBBLE knob with
SWIFT_DEBUG_RUNTIME_ALLOC_SCRIBBLE_BYTE, an optional_uint8 that lets
the user pick the actual byte to scribble. An unset value disables
scribbling. Default is 0xaa in NDEBUG-off builds and unset in release.
Add an optional_uint8 environment variable type and a parse_optional_uint8
parser so the .def entry can express the new behavior.
In an effort to disentangle the three sets of llvm headers the targets
in stlib uses (real llvm headers, RuntimeHeaders/llvm,
stdlib/include/llvm), this patch completely removes the includes from
the runtime to RemoteInspection.
This is the first patch to eventually completely remove
RuntimeHeaders/llvm headers.
We scan the target's initial allocation pool, and all 16kB heap allocations. We check each pointer-aligned offset within those areas, and try to read it as Swift metadata and get a name from it. If that fails, quietly move on. It's very unlikely for some random memory to look enough like Swift metadata for this to produce a name, so this works very well to print the generic metadata instantiated in the remote process without requiring `SWIFT_DEBUG_ENABLE_METADATA_ALLOCATION_ITERATION`.
rdar://161120936
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.
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.
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
We need a store-release when putting a new page onto the metadata allocator so that other threads see the initialization. We also need to tell TSan about our memory barriers here, to avoid false positives in __swift_instantiateConcreteTypeFromMangledName when it reads from memory allocated here.
rdar://145778813
The `-Winvalid-offsetof` warning is valid in this case. `offsetof` is
being applied to types with a non-standard layout. The layout of this
type is undefined by the specification. There is no guarantee that the
type layout is uniform across all ABIs. It is not possible to portably
compute the offset statically, especially efficiently.
Sink this check into a unit test to avoid performing this test at
runtime. In order to do this in the standard library, we would need to
do this check through a global constructor.
`Builtin.FixedArray<let N: Int, T: ~Copyable & ~Escapable>` has the layout of `N` elements of type `T` laid out
sequentially in memory (with the tail padding of every element occupied by the array). This provides a primitive
on which the standard library `Vector` type can be built.
The way that we include COMPATIBILITY_OVERRIDE_INCLUDE_PATH freaks out the
syntax highlighting of editors like emacs. It causes the whole file to be
highlighted like it is part of the include string.
To work around this, this patch creates a separate file called
CompatibilityOverrideIncludePath.h that just includes
COMPATIBILITY_OVERRIDE_INCLUDE_PATH. So its syntax highlighting is borked, but
at least in the actual files that contain real code, the syntax highlighting is
restored.
rdar://137066879
An unmanaged property does not map to an operation in CVW, instead it will be copied like primitive values. When instantiating the layout string, we correctly do not emit an operation, but we compute the offset to the next field as if we did. This is causing the offset to be incorrect and subsequent operations to be executed on the wrong address, causing crashes or other misbehavior.