* Revise the Unicode scalar/Character properties
* Minor revisions to `compactMapValues` docs.
* Add documentation for AdditiveArithmetic, revise Numeric
* Apply minor style updates to count(where:).
* Revise string interpolation docs.
- Convert table of interpolation examples to a list of examples. Tables
aren't supported by Swift markup, so this wouldn't render properly in
Xcode or on the web.
- Add a description of what a user must implement in a custom
string interpolation type to get the behavior they want.
* Revise isMultiple(of:) docs.
- In particular, add emphasis to mathematical symbols and equations to
match how we document such things elsewhere.
- I'm using asterisks for single symbols, and underscores for equations
because it's easier to read in-source when you don't have to escape
multiplication within emphasis.
* Add some abstracts to the SIMD vector types.
- Adds a dictionary of spelled out numbers. Only numbers < 10
should be spelled out according to editorial.
- Adds abstracts to some of the basic members.
- Includes parameter descriptions for the xyzw properties and inits,
but not for the unlabeled initializers. Combined with the protocol
extension method abstracts, this should complete coverage of the concrete
types.
This fixes the Windows platform, where the aligned allocation path is
not malloc-compatible. It won't have any observable difference on
Darwin or Linux, aside from manually allocated memory on Linux now
being consistently 16-byte aligned (heap objects will still be 8-byte
aligned on Linux).
It is unfortunate that we can't guarantee Swift-allocated memory via
Unsafe*Pointer is malloc compatible on Windows. It would have been
nice for that to be a cross platform guarantee since it's normal to
allocate in C and deallocate in Swift or vice-versa. Now we have to
tell developers to always use _aligned_malloc/_aligned_free when
transitioning between Swift/C if they expect their code to work on
Windows.
Even though this fix isn't required today on Darwin/Linux, it makes
good sense to guarantee that the allocation/deallocation paths are
consistent.
This is done by specifying a constant that stdlib can use to round up
alignment, _swift_MinAllocationAlignment. The runtime asserts that
this constant is greater than MALLOC_ALIGN_MASK for all platforms.
This way, manually allocated buffers will always use the aligned
allocation path. If users specify an alignment less than m
round up so users don't need
to pass the same alignment to deallocate the buffer). This constant
does not need to be ABI.
Alternatives are:
1. Require users of Unsafe*Pointer to specify the same alignment
during deallocation. This is obviously madness.
2. Introduce new runtime entry points:
swift_alignedAlloc/swift_alignedDealloc, introduce corresponding
new builtins, and have Unsafe*Pointer always call those. This would
make the runtime API a little more obvious but would introduce
complexity in other areas of the compiler and it doesn't have any
other significant benefit. Less than 16-byte alignment of manually
allocated buffers on Linux is a non-goal.
Add a vectored exception handler for illegal instructions on Windows.
This allows us to emulate `signal(SIGTRAP, ...)`. This allows better
coverage of tests.
Adjust the abort behaviour on Windows. The aborts would cause a large
number of dialogs to appear. This reduces the load a bit and is crucial
for getting tests to run without manual intervention.
Windows uses DOS line endings which appear through the PIPE endpoints.
We currently split on line feeds only, leaving the carriage return in
place. Without this, the messages on the communication pipe would not
be interpreted correctly.
This converts the path separators to the CMake way. This is primarily
important for Windows where the path separator is \ rather than /. This
conversion allows the specification of the path in the proper windows
path style.
The conversion routines in MSVCPRT return "0" for the conversion of
"-inf" et al. Provde template specializations for `float`, `double`,
and `long double` to use `strtof`, `strtod`, and `strtold` respectively.
This fixes the lossless conversion of floating point constants.
The inclusion of Windows.h would cause the Shims to depend on WinSDK, which
would in turn depend on MSVCRT. However, the SwiftShims are using in MSVCRT
causing a circular dependency between WinSDK and MSVCRT preventing a clean build
from succeeding. Break the dependency by only including libc headers in the
shims header.
The mapping of the return value of the `FlsAlloc` was flipped resulting
in the failure of the TLS key creation. The test suite would fail to
generate the TLS key resulting in failures.
Although technically these shouldn't be needed on Windows since there is
no compatibility to maintain since there is no version that exists
previously. However, this will ease porting of sources to the platform.
It also ensures that future tests added cover windows as well.
The swift variables use the upper case spelling while CMake uses mixed
case. Use the correct case to fix the build. This is preferable to
using MATCH to avoid the unnecessary configure time penalties.
Since handle's are so common place on Windows and the clang importer cannot
import the complex macro for INVALID_HANDLE_VALUE, define it locally to provide
an easier path to writing swift code on Windows. This repairs the Windows
builds.
We were creating a local Demangler instance, demangling a type name
using it, and then returning one of the resulting nodes to the caller.
Fixes rdar://problem/46817009.
Assume that the build currently targets only a single target. Use the target to
determine the linked libraries for the target library (swiftCore). This is more
precise and more importantly, is required to enable cross-compilation of various
targets.
We are now using Shell APIs for the command line parsing. Ensure that we link
against the Shell32 library. This is needed for the cross-compilation as on
Windows, the environment will set a default link against a number of libraries.
This is more precise and explicit.
We need to explicity ensure that an integer is in the required byte
order (little-endian in this case) before accessing it as an array
of bytes through an unsafe pointer.
Anonymous context descriptors were being treated as non-generic by
IRGen, which lead to problems for (file)private types within generic
types. Emit generic parameters and requirements for anonymous contexts
as well.
The runtime was mostly prepared for this, and the ABI already
accounted for it, so the runtime change is minor---it only affected
building a demangle tree from metadata.
Fixes rdar://problem/46853806.
Removes the _getBuiltinLogicValue intrinsic in favor of an open-coded
struct_extract in SIL. This removes Sema's last non-literal use of builtin
integer types and unblocks a bunch of cleanup.
This patch would be NFC, but it improves line information for conditional expression codegen.
