These would never be decoded in normal use, but it's possible to construct an archive that will attempt to decode them. Without this override, that throws an exception or worse.
rdar://problem/48429185
`String.+=` function to `String.append` function, and use a new
semantics attribute for String.+=.
Teach the constant evaluator about `String.Append` instead of `String.+=`.
A buffer's `rowBytes` doesn't have a direct relationship with its `height`, so `rowBytes / Int(width)` isn't a good way to calculate pixel size. To resolve this, I've added `pixelSize` as a parameter to `vImage_Buffer.copy`.
Now that that's stabilized, we don't have to keep them in Swift 4 mode
any longer. (Arguably we don't need the CMake variable at all, but it
may be useful again in the future.)
rdar://problem/49040980
* Add availability information to the new Math function protocols
The protocols ElementaryFunctions, RealFunctions, and Real are new in Swift 5.1 and accordingly need to have availability attached to them for platforms that are ABI-stable. The actual implementation hooks (static functions) are unconditionally defined on scalar types and marked @_alwaysEmitIntoClient, so they are available even when targeting older library versions, but the protocols themselves, and anything defined in terms of them (the global functions and the SIMD extensions) is only available when targeting library versions that have the new protocols.
* Additionally provide concrete implementations of signGamma for each stdlib-builtin floating-point type.
* Remove Real[Functions] protocols pending re-review
Temporarily pull these back so we can make minor tweaks to the design and get a re-review on SE.
We could introduce non-nominal-type context descriptors, such as those for opaque declarations,
which are also interesting to be able to look up for reflection or remote purposes. This should be
a backward compatible change with old runtimes, which always ignore any context descriptor kind
they don't know about.
This allows the conversion of the Windows `BOOL` type to be converted to
`Bool` implicitly. The implicit bridging allows for a more ergonomic
use of the native Windows APIs in Swift.
Due to the ambiguity between the Objective C `BOOL` and the Windows
`BOOL`, we must manually map the `BOOL` type to the appropriate type.
This required lifting the mapping entry for `ObjCBool` from the mapped
types XMACRO definition into the inline definition in the importer.
Take the opportunity to simplify the mapping code.
Adjust the standard library usage of the `BOOL` type which is now
eclipsed by the new `WindowsBool` type, preferring to use `Bool`
whenever possible.
Thanks to Jordan Rose for the suggestion to do this and a couple of
hints along the way.
Reviewed the cases of Glibc where branching occurred and checked the
skipped headers against the Android NDK sysroot, and added the Android
check in the right places. This will give access to a lot more
functions from libc.
* Restore elementwise min/max on SIMD, but as statics instead of free functions.
Having these as free functions causes expression too complex issues due to overload vis-a-vis min<Collection>. There are (at least) three plausible solutions:
1. Fix the typechecker. This is infeasable in the short term; or more precisely, we do not know how much work is involved.
2. Give these operations different names. Candidates discussed with core team include "pointwiseMin", "elementwiseMin", "lanewiseMin"; these all suffer from the flaw that when someone writes "min" in a SIMD context, they are essentially always looking for either the horizontal minimum (reduction) on a single vector or--more often--the lanewise minimum of two vectors (this operation). It would be odd to give the operation that people actually want the unnecessarily verbose name.
3. Make these operations static; this is, in effect, a different name, but it's one which frequently allows eliding the qualifier:
let x = v + .min(v, w)
This isn't perfect; you will still need to spell out SIMD4.min( ) fairly often, but that's more concise than any of the proposed alternatives, and at least allows elision some of the time. Also, if you squint, you can pretend that the "." prefix is like ".<" and ".&" and indicates lanewise operation.
* Accelerate vImage Swift Overlays
A suite of functions, enumerations, and option sets to make working with vImage in Swift simpler.
* vImage_Buffer - new initializers to instantiate and initialize buffers with a single function call.
* vImage_Buffer - new functions to copy buffers and create CGImage instances from contents.
* vImage_CGImageFormat - new initializers.
* vImage_CGImageFormat - new equivalence operator.
* vImageConverter - methods to wrap free functions.
* vImageConverter - new make and convert functions.
* vImageCVImageFormat - new make functions.
* vImageCVImageFormat - methods to wrap free functions.
* vImage_Error - errorDescription function.
* vImage flags as an option set.
* Add new methods for generating CV -> CG and CG -> CV converters.
* update comments: `height` and `width` to `size`.
* `vImage_CGImageFormat.componentCount` should be `Int`.
* `vImage_CGImageFormat.componentCount` should be `Int`
* Move `self.init()` to after the size check for kvImageNoAllocate init.
* Buffer initializers to width and height rather than size.
* change vImage_CGImageFormat lightweight initializer to accept Int for `bitsPerComponent` and `bitsPerPixel`.
* Flesh out docs for vImage_Buffer.size
* Remove faux initializer in favor of new static function: `preferredAlignmentAndRowBytes`.
* Change functions to use proper error handling rather than inout error codes.
* Removed `flags` from basic init.
The only real flag to pass here is print diagnostics to console, and I now throw proper errors.
* Tests to check error throwing for buffer copy.
* remove unnecessary import, add missing docs.
* Add comments to error enums.
* Fix bug creating string from format code.
* Make `vImageCVImageFormat.formatCode` a `UInt32`.
* Remove equivalence operator from `CGImageFormat`.
* Swift overlay to vDSP cascaded biquad IIR filter.
* update comment in test
* Swift overlay to vDSP Discrete Cosine Transform
* Swift Overlays to vDSP Fast Fourier Transform and Discrete Fourier Transform
* Tests for DFT and FFT
* Some refactoring and begin documentation.
* Swift overlays to FFT and DFT operations.
* Expand docs.
* Implement `vDSP_destroy_fftsetup` and `vDSP_destroy_fftsetupD`
* Refactor Tests
* Refactor Tests
* Provide transform function that returns the result. Refactoring: parameter names more consistent with other vDSP operations, push `fileprivate` symbols to bottom of file.
* Add apply() function that returns the result.
* Added a version of DFT transform that returns the result.
* update some DFT comments
* Remove FFT overlays from this branch to separate DFT and FFT pull requests.
* [Accelerate] [vDSP] Swift Overlays to FFT Operations
This PR contains Swift overlays to simplify performing 1D and 2D fast Fourier transforms on single- and double-precision data.
This PR includes a subset of the operations (e.g. vDSP_fft_zrop for FFT). My plan is to add the additional operations (e.g. multiple signals, in-place operations, etc.) in a subsequent PR once this is approved.
cc: @moiseev @airspeedswift @stephentyrone
* Composite Branch
Contains FFT, DFT, DCT, and Biquad branches.
Also have swift-reflection-test check if the symbol exists. This allows swift-reflection-test to work with older Remote Mirror dylibs that don't have it.
rdar://problem/50030805
Currently, `str.data(using:allowLossyConversion)` always bridges via
`NSString`.
As `String` is now natively UTF8 we can fastpath this conversion in the
case where the user requests UTF8 encoding.
A benchmark for this was previously added in #22648.
* Add missing cast to new vDSP_FIR overlay.
* Use macOS instead of OSX in availability annotations.
* Reorder Accelerate/CMakeLists.txt alphabetically.
Contains the following:
[Accelerate] [vDSP] Swift Overlays to Sliding Window Summation Operations
[Accelerate] [vDSP] Swift Overlays to Linear Interpolation Operations
[Accelerate] [vDSP] Swift Overlays to Complex Vector Operations
[Accelerate] [vDSP] Swift overlays to 1D and 2D convolution operations.
[Accelerate] [vDSP] Swift overlays to dot product and distance functions.
[Accelerate] [vDSP] Swift overlays to `vDSP_desamp` and `vDSP_deq22`.
[Accelerate] [vDSP] Vector Reduction Functions
[Accelerate] [vDSP] Elementwise Vector-Vector and Vector-Scalar Arithmetic
[Accelerate] [vDSP] Miscellaneous Conversion Functions
[Accelerate] [vDSP] Polynomial Evaluation Functions
[Accelerate] [vDSP] Clipping, Limit, and Threshold Functions
[Accelerate] [vDSP] Fill, Clear, and Generation Functions
[Accelerate] [vDSP] Integration Functions
[Accelerate] [vDSP] Vector Type Conversion Functions
[Accelerate] [vDSP] Swift overlays to Vector-Vector Extrema and Single-Vector Operations
