CMake supports the notion of installation components. Right now we have some
custom code for supporting swift components. I think that for installation
purposes, it would be nice to use the CMake component system.
This should be a non-functional change. We should still only be generating
install rules for targets and files in components we want to install, and we
still use the install ninja target to install everything.
* [Accelerate] [vForce] New vForce Overlay
This PR contains a suite of overlays to the vForce transcendental and trigonometric functions on vectors of any length. The overlays simplify the API to the existing functions and accept collections that implement a new protocol called AccelerateBuffer. Conformances are provided for the most useful stdlib Collections.
In protocol extensions, and in the future parameterized extensions, have their own generic arguments
independent of an originating nominal type's formal generic parameters. Instead of crashing, handle
this gracefully. rdar://problem/50038754
* [Accelerate] [Quadrature] New Quadrature Overlay
A class that simplifies approximating the definite integral of a function.
* Fixes in response to PR Review.
Change `@_exported import Accelerate` to `import Accelerate`.
Correct date in copyright comment.
* Code Review Fixes.
* Remove mutable integrator, simply set options in init().
* Remove mutable `maxIntervals` and `qagPointsPerInterval`.
* Update tests.
* Code Review Fixes.
* Use standard library `Result`.
* Implement `QAGPointsPerInterval` as a struct.
* Tidy up Passing Integrand to `quadrature_integrate_function`.
Pass the integrand closure directly to the `quadrature_integrate_function` initialiser rather than attaching as a property of the `Quadrature` class.
* Make `Quadrature` a struct, and remove requirement for `integrand` to be escaping.
* Code Review Changes
* Add long-form integrator algorithm aliases (update tests to use these aliases).
* Make quadrature error description public.
* New tests for error description and `QAGPointsPerInterval`.
* Vectorized Integrand for Quadrature
Create an alternative implementation of `integrate` that accepts an integrand of type `(_ input: UnsafeBufferPointer<Double>, _ result: UnsafeMutableBufferPointer<Double>)`.
* Vectorized Integrand for Quadrature
Create an alternative implementation of `integrate` that accepts an integrand of type `(_ input: UnsafeBufferPointer<Double>, _ result: UnsafeMutableBufferPointer<Double>)`.
* Vectorized Integrand for Quadrature
Remove _ContiguousCollection - it's no longer used.
* Delete ContiguousCollection.swift
Not required.
* Refactor tests.
This implements the protocols and static functions proposed in SE-0246, plus some initial test coverage. It also has some rough accompanying cleanup of tgmath. It does not include the globals (on scalars or SIMD types) nor does it deprecate much in tgmath.h.
In the prior revision, this file combined two approaches:
- the old approach of doing some fun things with arrays and hoping
that any important public and internal generic symbols will happen
to be specialized
- the new approach of explicitly specializing a generic symbol by
annotating a dummy "proxy" function with the actual generic mangled
name, then calling that proxy with an argument of the type to be
specialized.
Unfortunately, the symbols exposed by SwiftOnoneSupport have become
ABI. Therefore, the old approach can break over time because changes
to the compiler and standard library will affect which symbols happen
to be specialized. It can be extremely difficult to debug why those
symbols have gone missing.
The new approach will work to ensure ABI stability, but the
implementation was incomplete and the style of implementation would
not work in many cases. It was still relying on the old approach to
cover the generic symbols that weren't explicitly specialized. Also,
it wasn't clear to anyone reading the source what specializations of
those generic symbols are intended and required by the ABI.
This commit completely removes the old approach to prespecialization.
All generic symbols required by the ABI are now explicitly listed.
There are now several different proxy functions declared as methods
within the generic type that they represent. The parameter types of
each proxy function now match the parameter types of the generic
function. This guarantees that the compiler can correctly apply the
proxy function's subsitution map to the generic function's generic
signature. For example, it now handles subtitution of dependent types
(like Range<T>), substitutions that are not in the first parameter
position, and subsitition that occur in multiple parameters.
The proxy functions are now directly invoked with the concrete
argument type needed for specialization. There's no other incidental
code.
It is now possible to read this source and understand which standard
library functions need to be prespecialized on which types.
_swift_stdlib_getHardwareConcurrency's declaration isn't a proper prototype:
it's missing `void` inside the brackets.
Found while compiling the stdlib to WebAssembly, which fails with:
Functions with 'no-prototype' attribute must take varargs: _swift_stdlib_getHardwareConcurrency
This shouldn't impact existing platforms.
The `ObjectIdentifier(object as AnyObject)` is not necessarily stable; this breaks reflexivity for ==, and it makes the hash encoding nondeterministic.
These are triggering a bad compile-time regression for some expressions; that's a bug that should be fixed, but we don't know how to fix it yet, so we'll need to remove these in the short-term, and possibly spell them differently in the medium term.
The purpose of this module is to prespecialize generic methods in the
stdlib. All symbols exposed by the ABI must be explicitly identified
to maintain ABI compatibility. Some of those ABI-exposed symbols
reference internal stdlib types.
Given that we want the prespecialized code to live in the separate
SwiftOnoneSupport library, and we want the module to explicitly list
all the symbols required for ABI stability, there's no way around
disabling access control when building it. In fact, that flag does
precisely what we want.
This should be harmless because
- no one imports SwiftOnoneSupport.swiftmodule
- these internal symbols were always being exposed in
SwiftOnoneSupport.dylib, so nothing changes there
