Enabling CloudKit on watchOS required to remove some default .ctor that
watchOS does not _support_.
This commit fix this by either
* replacing the default .ctor with something that works across all
platforms (best); or
* removing the default .ctor only on watchOS;
The commit also mark as abstract three existing types for watchOS (and
for XAMCORE_4_0) that were found reviewing the bindings.
Runtime
- Added support for Vector2d, Vector3d and Vector4d SIMD types
- Added support for GKBox, GKQuad and GKTriangle SIMD types
GameplayKit
- Apple introduced GKQuadTreeNode and GKQuadTree in Xcode 7.1 and
removed those types in a later Xcode (7.2?) but we kept them around.
Now apple introduced again both types but renamed them to GKQuadtreeNode
and GKQuadtree (lowercase t), this is a breaking change and since we do
care about binary compat we are just changing the registration name and
keeping the same managed name deprecating old methods and introducing
the new ones.
- Added tests for new SIMD types
Xcode8 SDK changed untyped enums (always 32 bits) into NSInteger. In this
case we can continue with the existing API (and ignore them in xtro)
reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=42682
note: AVFoundation is commented on watchOS 3 as this breaks the static
registrar .a helper built for watchOS.
AVFoundation does a file check to enable some types - but the watchSimulator
include that file, leading to compilation errors later (missing CMTime.h)
#if TARGET_OS_WATCH
#if ! __has_include(<AVFoundation/AVAnimation.h>)
#define AVF_IS_WATCHOS_SDK 1
#endif
#endif
Remove use of manual code by moving INImage_IntentsUI directly inside
intents.cs. Final API remains identical and this makes xtro pick them
up correctly.
It turns out `setDepthClipMode` was removed in Xcode 8, so this needs
some manual code to maintain binary compatibility
references:
!extra-protocol-member! unexpected selector MTLRenderCommandEncoder::setDepthClipMode: found
!unknown-native-enum! MTLPrimitiveTopologyClass bound
Native code can provide the same native method for blocks
with different managed signatures, so it's not enough
to hash by method address, we need to take the target type
of the delegate into account as well.
https://bugzilla.xamarin.com/show_bug.cgi?id=34513
No news from Apple on the original rdar but the issue was fixed in Xcode
8 beta 6 (and likely earlier betas)
> MP_EXTERN_CLASS_AVAILABLE(3_0)
> @interface MPMediaItemArtwork : NSObject
which makes it possible to enable the type (as it does nor depend on
other, unavailable, types).
references:
* rdar://24982126
* https://trello.com/c/2gxuFbeS
It's the only one, so it's kind of designated, but it's not marked as
such in the header files and it's better matching them (xtro test wise)
reference:
!extra-designated-initializer! MPSMatrixMultiplication::initWithDevice:transposeLeft:transposeRight:resultRows:resultColumns:interiorColumns:alpha:beta: is incorrectly decorated with an [DesignatedInitializer] attribute
reference:
!missing-designated-initializer! SFSafariViewController::initWithURL:entersReaderIfAvailable: is missing an [DesignatedInitializer] attribute
Some types were removed in tvOS 10, including:
!unknown-protocol! AVAssetDownloadDelegate bound
!unknown-type! AVAssetDownloadTask bound
!unknown-type! AVAssetDownloadURLSession bound
!unknown-type! AVAudioInputNode bound
and we're replacing them with stubs so our binaries won't contain any of
the selectors that could be rejected by Apple on the app store
Some (new) fields are also not part of tvOS (and were not in iOS either)
!unknown-field! AVVideoCodecAppleProRes422 bound
!unknown-field! AVVideoCodecAppleProRes4444 bound
!unknown-field! AVVideoColorPrimaries_EBU_3213 bound
!unknown-field! AVVideoTransferFunction_SMPTE_240M_1995 bound
!unknown-field! AVVideoYCbCrMatrix_SMPTE_240M_1995 bound
* [tests][xtro] Many categories are not marked as not available on tvOS, even if the type being extended is not available. This adds entries for them so only missing AV* API remains in tvos.unclassified
In bug #43592 the following occurs:
* App calls an API that takes a block.
* We create a stack-based ObjC block based on the delegate the app provided.
This block has a pointer to a block description, describing the block
in question (including the signature of the block, as an ObjC-type
encoded string). We allocate a new block description for every block.
* Apple's API stores the pointer to the signature string somewhere.
* Apple calls _Block_copy to get a heap-based block.
* We create a heap-based block, and copy the entire description into the
new heap-based block (including a copy of the signature).
* Apple returns from the API, and then we free the stack-based block
(and the descriptor, and thus the signature string in the descriptor).
* Apple uses the pointer to the signature stored previously to investigate
the signature of the block, and crashes because this signature has been
freed.
The assumption in Apple's code is that the description will never be freed,
which is true for any Xcode project (clang will always be able to create the
block description at compile-time and emit it in the binary, which means the
memory will never be freed). We could potentially do the same thing in the
static registrar, but we'd still need a solution when using the dynamic
registrar.
To fix this instead of copying the entire description structure when creating
a heap-based block from the stack-based block, we make the description ref-
counted, and just use the same description in the heap-based block.
The signature will now stay in memory until both the heap-based and stack-
based blocks have been freed, and we hope Apple doesn't have any API that
needs the signature after all the blocks for that signature have been freed.
https://bugzilla.xamarin.com/show_bug.cgi?id=43592
CALayerDelegate was an informal protocol in earlier versions
of iOS, but elevated to protocol in iOS 10 [1]. Unfortunately this causes
problems with the static registrar, since it needs to know if a protocol
is informal or not to generate the right code, but there's no way
with the current set of attributes we have to express the fact that
CALayerDelegate was an informal protocol until iOS 10, so the static
registrar don't know to treat it correctly when building with earlier
SDKs.
This is the error that results when using CALayerDelegate with an earlier SDK:
/work/monotouch-samples/ZoomingPdfViewer/obj/iPhone/Debug/mtouch-cache/registrar.m:1336:51: error: no type or protocol named 'CALayerDelegate'
@interface ZoomingPdfViewer_TiledPdfView : UIView<CALayerDelegate> {
^
So we temporarily revert the change to make CALayerDelegate formal,
until we have enough metadata for the static registrar to do the
right thing (which is filed as bug #43780 [2])
[1] https://github.com/xamarin/xamarin-macios/commit/0178aa04
[2] https://bugzilla.xamarin.com/show_bug.cgi?id=43780https://bugzilla.xamarin.com/show_bug.cgi?id=43585
Alex Soto
Sebastien Pouliot
Sebastien Pouliot
Rolf Bjarne Kvinge
Chris Hamons
Manuel de la Pena
Jeffrey Stedfast