This makes for a cleaner and less implicit-context-heavy API, and makes it easier for symbolic
reference resolvers to do context-dependent things (like map the in-memory base address back to a
remote address in MetadataReader).
We don't want objc_getClass and NSClassFromString to be able to feed arbitrary symbolic reference
pointers into the Swift runtime. Fixes rdar://problem/54724618.
It is causing bots to fail.
* Revert "The __has_include(<os/system_version.h>) branch here wasn't quite right, we'll just use the dlsym one for now"
This reverts commit f824922456.
* Revert "Remove stdlib and runtime dependencies on Foundation and CF"
This reverts commit 3fe46e3f16.
rdar://54709269
This commit introduces a CMake target for each component, adds install targets
for them, and switches build-script-impl to use the target `install-components`
for installation. Each of the targets for each component depends on each
of the individual targets and outputs that are associated with the
corresponding swift-component.
This is equivalent to what already exists, because right now install rules are
only generated for components that we want to install. Therefore, this commit
should be an NFC.
This is a resubmission (with modifications) of an earlier change. I originally
committed this but there were problems with some installation rules.
Instruments relies on the old values being there so it can call the original implementation. This has very slightly worse codegen but the impact should be minimal.
An extension on a class creates a conformance record that's always visible even when that class is not present at runtime. In that case, the type pointer in the conformance record is NULL. The runtime did not like this, and crashed. This fixes it to ignore such records instead.
rdar://problem/54054895
This is a one-to-many cache that's more speculative than the cache mapping mangled names to context descriptors. Entries found in the cache need to be verified for a match before they can be returned. However, this allows scanning conformance records up front and building up the cache in one scan rather than performing an expensive scan of all conformance records every time the mangled name cache misses.
rdar://problem/53560010
This commit introduces a CMake target for each component, adds install targets
for them, and switches build-script-impl to use the target `install-components`
for installation. Each of the targets for each component depends on each
of the individual targets and outputs that are associated with the
corresponding swift-component.
This is equivalent to what already exists, because right now install rules are
only generated for components that we want to install. Therefore, this commit
should be an NFC.
This change modifies spare bit masks so that they are arranged in
the byte order of the target platform. It also modifies and
consolidates the code that gathers and scatters bits into enum
values.
All enum-related validation tests are now passing on IBM Z (s390x)
which is a big-endian platform.
Functions like swift_retain call through a function pointer so that Instruments can interpose. This slows down the common case where there is no interposition. Instead, initialize the function pointers to NULL and call through directly to the real implementation when it's NULL. The compiler is smart enough to inline this call and the result is a single conditional branch rather than a function pointer call.
rdar://problem/18307425
When looking for a context descriptor for a protocol extension, we
search based on the mangled name--"x", a generic type parameter with
depth and index 0--and are guaranteed to fail because there is no such
concrete type. However, _findContextDescriptor will fail very slowly,
spinning through all of the types and conformances in all of the
loaded images. Moreover, negative results aren't cached, so this can
happen repeatedly.
Short-circuit _findContextDescriptor when it receives a dependent
generic type parameter type, avoiding the expensive search when it
will find nothing.
Potential fix for rdar://problem/53560010.
This commit centralizes the code that converts variable length
tag values, stored in enum payloads and extra tag bytes, to and
from the 4-byte integer values that the runtime uses to represent
the enum case.
Note that currently big endian machines will store the tag value
in the first word of the destination. This reflects the current
behaviour of the compiler. I am however expecting to change this
so that the value is stored as a true variable-length big-endian
integer in the near future, so the tag value will be stored in
the last 4 bytes of payloads rather than the first 4 bytes like
they are on little-endian systems.
The memcpy in the type layout verifier was not correct for big-
endian systems. While we are here change 'long long' to a fixed
width unsigned type (uint64_t). It doesn't really make sense to
print the value as a signed number since we have zero extended
it from its original bit width using the memcpy.
Generic parameters for a context are normally classified as "key",
meaning they have actual metadata provided at runtime, or non-key,
meaning they're derivable from somewhere else. However, a nested
context or constrained extension can take what would be a "key"
parameter in a parent context and make it non-key in a child context.
This messes with the mapping between the (depth, index) representation
of generic parameters and the flat list of generic arguments. Fix this
by (1) consistently substituting out extension contexts with the
contexts of the extended types, and (2) using the most nested context
to decide which parameters are key, instead of the context a parameter
was originally introduced in.
Note that (1) may have problems if/when extensions start introducing
their /own/ generic parameters. For now I tried to be consistent with
what was there.
rdar://problem/52364601
`StaticBinaryELF.cpp` was listed as an optional source but then unused
by any build target. As a result, it escaped detection that the file
was no longer in use.
Unfortunately, `std::atomic` in msvcprt as of 14.21.27702 is broken for
double-width atomics on ARM64. This has been reported to Microsoft and
is going to be fixed in VC++ 2019u3. For the time being, add a partial
template specialisation for the two double-word sized types temporarily
as a workaround. This allows the standard library build to get further.
There are situations where you want to build against a libc that is out
of tree or that is not the system libc (Or for cross build scenarios).
This is a change for passing the -sdk and include paths for things like
this.
