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.
* Remove doc comments from concrete floating-point types
... when they are already present on the protocol. I don't *think* that we need them anymore for xcode documentation purposes. There are reasonable arguments both ways on this:
1. when you're editing the concrete implementations, it's sometimes nice to have the doc comment right there.
2. but it needlessly repetitive, and introduces the opportunity for comments to get out of sync.
3. it also adds noise; it would be nice for information density if the implementation only had implementation notes.
* Add examples to documentation for FloatingPoint.isCanonical
In particular, document that subnormal encodings are treated as non-canonical zeros on platforms that flush to zero.
* Additional fixes by @xwu and @natecook1000 .
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 makes it more explicit what the install component of a target
library is if you don't see one (and its marked as IS_SDK_OVERLAY).
Explicit in this case makes more sense, as you don't have to rely on
knowledge of how `add_swift_target_library` is implemented to understand
what component is used to install the target.
One additional tweak (setting the scalar-aligned bit on foreign indices) had to be made to avoid a performance regression for long non-ASCII foreign strings.
Check if building on Android through the ANDROID_DATA environment variable, then set
SWIFT_ANDROID_NATIVE_SYSROOT to the default layout for the Termux app, and key all the
include, lib, and other SDK paths off of that. The system libc and a few other libraries
are linked against from /system/lib[64]. Finally, check if lit is running natively on
Android and don't use adb if so.
__swift_size_t on Windows is a size_t, which makes it potentially a
64-bit integer. ULONG, however, is always a 32-bit integer, and so this
cast risks shrinking the apparent size of the cbBuffer argument to
BCryptGenRandom. The effect of that will be to underfill the buffer,
leaving it full of uninitialized memory that we would treat as random.
The actual risk from this in the current implementation is basically
zero, as user code can only ever invoke this with an argument size of 8.
There's no good reason to leave this sharp edge on the API though.
Static builds of the standard library and the SDK overlay are
unsupported post ABI stability. Disallow building of the standard
library and SDK overlay statically for Darwin platforms.
For using the improved condfail messages in the stdlib, we need a function, like precondition(), just taking a StaticString instead of a String for the message.
The existing (underscored) _precondition is a perfect fit for this, except that it's not printing the location info in debug builds.
This change makes _precondition() equivalent to precondition, just taking a StaticString as argument.
The other alternative would be to add another variant of precondition, just taking a StaticString. But we already have so many failure functions in Assert.swift, so adapting an existing one seems to be a better solution.
This effectively undos a change from 5 years ago which intentionally removed the location info from _precondition (rdar://problem/16958193). But this was at a time where swift was not open source yet. So I think today it's okay to always add location information, even if it's from inside the stdlib. It can be even very useful for expert users for looking up the location the stdlib source.
The SIL generation for this builtin also changes: instead of generating the cond_fail instructions upfront, let the optimizer generate it, if the operand is a static string literal.
In worst case, if the second operand is not a static string literal, the Builtin.condfail is lowered at the end of the optimization pipeline with a default message: "unknown program error".
