CHIP framework seems to not be stable yet from Apple's side
each xcode update it brings breaking changes and it is also
not documented anywhere so let's disable it for now and
we can re-enable it in the future once it is stable.
It exists, but does nothing on Mac Catalyst.
"This framework ignores calls from Mac apps built with Mac Catalyst."
Ref: https://developer.apple.com/documentation/arkit?language=objc
Also augment xtro to not be confused when encountering lines starting with '#'
that has no other text.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* Set NSImageRep DrawInRect hints as nullable
* Add nullable attributes to NSString DrawAtPoint/DrawInRect/StringSize
* Fix xtro test failure
Co-authored-by: Chris Hamons <chris.hamons@xamarin.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
This also requires updating the xtro definitions, because sharpie now finds
many more Mac Catalyst frameworks than before (and we haven't bound those
frameworks yet).
Generate a proj file that contains variables for the current pch and assembly,
and include this proj file in the main xtro-sharpie project file. This way we
can use these variables for the pch and assembly arguments in the run
configurations, so we don't have to update the project file every time these
change (in particular the pch file changes name with every Xcode bump).
* Add to Mac Catalyst. Fixes#13931.
* Manually include CoreTelephony headers in xtro. There's no umbrella header
in CoreTelephony 😡😞
* Fix availability attributes
* Only CTCall and CTCallCenter are deprecated in the CoreTelephony API.
* None of these APIs are obsolete, just deprecated.
* Add Mac Catalyst attributes.
One curious fact is that the PCSC framework interferes with compiling CTCarrer.h:
In file included from /private/var/folders/43/h027tm1n101cdrq2_b6n9n2m0000gn/T/n0b0byrt.h:163:
/Applications/Xcode_13.2.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/CoreTelephony.framework/Headers/CTCarrier.h:62:41: error: reference to 'BOOL' is ambiguous
@property (nonatomic, readonly, assign) BOOL allowsVOIP __OSX_AVAILABLE_STARTING(__MAC_NA,__IPHONE_4_0);
^
/Applications/Xcode_13.2.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/PCSC.framework/Headers/wintypes.h:59:18: note: candidate found by name lookup is 'BOOL'
typedef int16_t BOOL;
^
/Applications/Xcode_13.2.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/usr/include/objc/./objc.h:78:18: note: candidate found by name lookup is 'BOOL'
typedef bool BOOL;
^
1 error generated.
but since we don't bind the PCSC framework, we can just ask ObjectiveSharpie
to exclude it.
Fixes https://github.com/xamarin/xamarin-macios/issues/13931.
* Remove ObjCRuntime.nfloat (in favor of System.Runtime.InteropServices.NFloat).
* Automatically add a reference to the System.Runtime.InteropServices.Internal
package, so that developers get the new NFloat API (with operators) we've
added post .NET 6 (but don't do this for .NET 7).
* Automatically add a global using alias for
System.Runtime.InteropServices.NFloat -> nfloat. This is not behind the
usual `ImplicitUsings` condition our other implicit usings are, because
they're off by default for existing projects, and the main target for the
global using alias for nfloat is upgraded projects.
* Automatically generate a global using alias (like above) in the generator
for all code the generator compiles.
* Update xtro entries to reference System.Runtime.InteropServices.NFloat
instead of ObjCRuntime.nfloat.
* Add a workaround for a hopefully temporary issue with .NET/CoreCLR where the
wrong runtime pack is selected otherwise (without the new NFloat API, so
nothing works at runtime).
Ref: https://github.com/xamarin/xamarin-macios/issues/13087
* Remove the code behind for AVCaptureConnection.SupportsVideoMinFrameDuration
and AVCaptureConnection.SupportsVideoMaxFrameDuration. The codebehind looks like
a workaround for Apple renaming the selector, but from history it looks like that
happened before the earliest version of iOS we support today, so this can be expressed
in an api definition now without any code behind.
* Add these fields to macOS, where they're not even deprecated (like they are on
other platforms).
* Remove conditional code in api definition, and distribute [No*] attributes as
required.
* Remove the AVCaptureConnection.AudioChannels property from .NET, it doesn't do
anything useful.
Rename our product assemblies to:
* Microsoft.iOS.dll
* Microsoft.tvOS.dll
* Microsoft.macOS.dll
* Microsoft.MacCatalyst.dll
This makes it easy to distinguish between legacy Xamarin and .NET whenever the
product assembly is mentioned, and I've also chosen the platform part of the
name to match how the platforms are named elsewhere (this also makes it
possible to simplify our build logic, since we can remove a lot of special
casing).
Fixes https://github.com/xamarin/xamarin-macios/issues/13748.
fixes#13160
- remove unused types
- use System.Numerics when possible
- move own created types from OpenTK namespace to CoreGraphics
- create missing types in CoreGraphics namespace
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Removing attributes for mellite
* Remove existing attributes
* Attribute Conversion
* Reverting changes to Security/Enums.cs and Security/SecureTransport.cs since they are API source
* Revert "Removing attributes for mellite"
This reverts commit eea2898870.
* Fixing Verifies, Moving Obsolete, Adding missing conversion
* Adding in removed comments and messages
* Removing unused NET Attributes
* Removing duplicated comments
* Removing not needed availability
* Remove todos
* removing other not needed availability
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Implement the UIResponderStandardEditActions protocol, move the
corresponding API from UIResponder there, and make sure UIResponder implements
the new UIResponderStandardEditActions protocol (which should make this move a
non-breaking change, since the protocol is inlined in UIResponder).
* A lot of obsolete/deprecated removal.
* Remove the NSDraggingInfo model, which required numerous other changes.
* Remove the NSPasteboardReading/NSPasteboardWriting models, which required more
numerous changes.
* Update the tests accordingly.
* [CHIP] Updates for Xcode13.2 beta 1
* Update based on feedback
* Update based on feedback and intro test failure
* Update xtro .todo files
* Fix some breaking API changes
* Delete silly typos
* Mostly just removal of obsolete/deprecated API.
* Modified CAScrollLayer.ScrollMode to use the good name
(CAScrollLayer.ScrollMode) for the strongly typed enum, and then have a
WeakScrollMode property for the NSString version (like we do elsewhere).
* Use the native `NSStringFrom*` API so we can, eventually, use the
native code to parse them from `NSString` and also ensure increased
compatibility with any code that expects the native string representation
* Add unit tests for `ToString` methods
Also use [`System.HashCode`](https://docs.microsoft.com/en-us/dotnet/api/system.hashcode?view=net-6.0) to generate the hash code
* Improve the API for both legacy Xamarin and .NET.
* Obsolete the old API in legacy Xamarin and point to the new API.
* Remove the old API in .NET.
* Add nullability.
This is mostly removing obsolete/removed API, except for
SKProduct.ContentVersion, where the XAMCORE_4_0 annotations were wrong and the
property is still alive and kicking.
This means removing numerous obsolete/deprecated methods where better/more
correct alternatives already exist.
Also fix one obsolete message and adjust the tests.
These types come from the CFNetwork.framework, but for some reason they were bound inside CoreServices many years ago.
This resolves a potential issue where we might end up linking with the
CoreServices framework instead of CFNetwork framework (because we use the
namespace of types to determine which framework they belong to).
It's our own enum, and all the API using it have been obsoleted/removed.
There doesn't seem to be any other usage of it on GitHub either (only our own
source code and documentation).
Also remove the Unscaled field, it's removed from the headers, and it was
deprecated before the earliest macOS version we support.
Also also fix a few xtro issues.
* [Xcode13.2] Bump to Xcode 13.2 RC (#13497)
* [Xcode13.2] Bump to Xcode 13.2 Beta 2
Breaking changes addressed for legacy
* HomeKit
* CallKit
* CoreLocation
* [xcode13.2] Bump to Xcode 13.2 RC and apply feedback
* [AppKit] Fix missing Notifications
* Fix xtro
* [xcode13.2] Bump versions and use stable Xcode 13.2
* [monotouch-tests] Make TestAddingByComponents work on the last day of the year
Happy New Year!!
* NO BOM PLZ!
Once upon a long time ago we decided to mark the properties in the
UITextInputTraits protocol as required in our API definition, because that way
we'd inline these properties in any class that implemented the
UITextInputTraits protocol, which made calling these properties much easier.
At a later point, we implemented better support for protocols, and now we
automatically generate extension methods for such properties (a corresponding
Get/Set method for the get/set property accessors), so we don't need these
inlined properties anymore.
However, removing them would be a breaking change, so we were stuck with these
redundant inlined properties, until .NET came along.
Ref: 0e80570863
Fixes https://github.com/xamarin/xamarin-macios/issues/5831.
If NSFunctionKey isn't in Mac Catalyst in legacy Xamarin, it shouldn't be in
.NET either, so adjust the conditional logic accordingly.
Also make the NSFunctionKey enum a non-native enum in .NET, like it's in the
headers.
* Change all XAMCORE_4_0 conditions to NET conditions.
* Add numerous Release attributes that xtro started complaining about.
* Misc other minor API changes/updates.
* [src] Add missing availability attributes in a few places.
* [src] Don't add availability attributes to error enums.
* [introspection] Change version check for Mac Catalyst to be 'greater than'.
We have a tests that verifies that the availability attributes for an API
doesn't state that the API was deprecated before or when it was introduced.
This sounds reasonable, except that Apple has introduced and deprecated entire
frameworks in the same Mac Catalyst version (probably because Apple decided to
port an already deprecated framework to Mac Catalyst).
Our test for this scenario was a bit too eager; this change will make it so
that (for Mac Catalyst only), we accept APIs that are introduced and
deprecated in the same Mac Catalyst version (not not APIs that were deprecated
before they were introduced).
* [AppKit] Change NSTextViewDelegate.DraggedCell to use the recommended signature for .NET
The 'textView:draggedCell:inRect:event:' selector has been deprecated since
macOS 10.6, so just replace this with the recommended alternative.
* [generator] Make sure code compiles for parameter names that match C# keywords.
* We don't want availability attributes for enums that represent errors,
because the code would end up unnecessarily complex to avoid warnings.
* We even have other tests to verify as much (cecil tests).
The former has been removed from the headers, so it's thoroughly deprecated,
and the latter is no longer needed anymore since it was only used by the
former.
Delete the 'osx.pending' file, it's not used. It looks like it should have
been removed in fffaba2414 (where the *.pending
files for the other platforms were removed).
* Use proper dependency tracking, so that we'll only rebuild what needs to be rebuilt
when rebuilding. This required using a few stamp files. It also improves parallel
builds.
* Remove *.raw files before running xtro-sharpie, and only for the current platform.
This makes sure rebuilds of just some of the platforms work correctly (because
the *.raw files for other platforms are still around when needed).
* Build the u2todo project file instead of manually calling csc.
* LAContext.MaxBiometryFailures is available in macOS, just deprecated, so mark
it as such.
* Remove deprecated code from .NET.
* Update xtro definitions.
* Unify the signed and unsigned implementations. We lose some type-safety (because
we have to use 'object' as the unifying type between long and ulong), but we minimize
code duplication, so the code becomes easier to maintain.
* Add an additional check for managed enum values that show up in the native header,
but aren't available on the current platform.
This makes it easier to iterate over all the *_SDK_VERSION variables in
template code, because they're all named using the standard platform names we
use elsewhere.
There are numerous checks that don't make much sense to report for deprecated
API, so skip those. This also required updating a few .ignore and .todo files.
Removes the following warning during the builds:
```
warning CS8767: Nullability of reference types in type of parameter 'host' of 'bool NSHost.Equals(NSHost host)' doesn't match implicitly implemented member 'bool IEquatable<NSHost>.Equals(NSHost? other)' (possibly because of nullability attributes)
```
Test was added to ensure that we did not throw an exception.
Apple does this in their headers:
#define DISPATCH_ALIAS_V2(sym) __asm__("_" #sym "$V2")
dispatch_queue_t
dispatch_queue_create_with_target(const char *_Nullable label,
dispatch_queue_attr_t _Nullable attr, dispatch_queue_t _Nullable target)
DISPATCH_ALIAS_V2(dispatch_queue_create_with_target);
Which means that the native compiler will call
'dispatch_queue_create_with_target$V2' when the source code says to call
'dispatch_queue_create_with_target'.
The only place I've run into this problem, is when building for tvOS (device),
and targetting exactly tvOS 10.0 (neither earlier or later), in which case the
linker fails:
Undefined symbols for architecture arm64:
"_dispatch_queue_create_with_target", referenced from:
wrapper_managed_to_native_CoreFoundation_DispatchQueue_dispatch_queue_create_with_target_string_intptr_intptr in Xamarin.TVOS.dll.o
I filed this as a feedback with Apple some time ago [1], and Apple resolved it
as by design, saying "These symbols are renamed, please use the SDK."
Now I ran into it again with .NET, and it's become a bit more important, since
tvOS 10.0 is the earliest tvOS version we support, which means it'll be more
likely that customers use _exactly_ 10.0 as their target tvOS version. So I
looked into it again, and as far as I can tell, we can just call the '$V2'
variant instead of the original name everywhere.
Apple does the same thing for two other functions, but we haven't bound any of
those, so this only affects 'dispatch_queue_create_with_target' for us.
[1]: Bug ID 48076044: Can't reference 'dispatch_queue_create_with_target' when min tvOS version is exactly 10.0
Web documentation mention them to be available. Introspection disagree.
Since they are all related to a single `VideoCallSupport` category, this
feature is likely not available to Catalyst.
The framework is only available on macOS 12.
It's possible (my guess) that the selectors were renamed after Xcode 13
beta 5 was released. In that case a future (RC?) Xcode will have the
updated headers.
Most selectors are working as expected
```
NSLog (@"%@", [MEMessageAction markAsReadAction]);
Message Action: Destination: (null), Read Status: 1, Flag Change: (null), Message Color: 0
```
while the last 3 do not work, even from an ObjC application
```
NSLog (@"%@", [MEMessageAction flagAction]);
+[MEMessageAction flagAction]: unrecognized selector sent to class 0x7ffa601fc5d8
```
```
NSLog (@"%@", [MEMessageAction unflagAction]);
+[MEMessageAction unflagAction]: unrecognized selector sent to class 0x7ffa601fc5d8
```
```
NSLog (@"%@", [MEMessageAction setColorActionWithColor:(MEMessageActionMessageColorRed) ]);
+[MEMessageAction setColorActionWithColor:]: unrecognized selector sent to class 0x7ffa601fc5d8
```
This requires a small change to the generator since `Selector.FromHandle`
can return `null` but it does not means the invoked API can (and we are
interested in the later).
Fixed up existing API returning potentially `null` `Selector`, IOW adding
the missing `[NullAllowed]` on them and updating xtro.
* A lot of availability attribute updates.
* Some conditional "#if !__MACCATALYST__" in manual binding files.
* xtro updates.
* Misc other minor tweaks.
A new check was added to ensure that empty .todo files are not added,
yet when the sanitizer removes all lines we get an error per empty file.
Since we are auto-sanitizing, we want to remove those empty files.