Ref: aa13dcb506
First line in the description is:
> Fixed CFWriteStream.DoGetProperty to call CFWriteStreamCopyProperty (and not CFReadStreamCopyProperty)
But that's not what the actual change does.. so change it to do the right thing.
This is a manual and squashed backport of
https://github.com/xamarin/xamarin-macios/pull/19717 and it was updated
to use Xcode 15.2 since Xcode 15.2 contains the same SDKs as Xcode 15.1
but Xcode 15.2 has visionOS SDK and it is the new stable release from
Apple.
---------
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Adding up for review but will block its landing until the PR
https://github.com/xamarin/xamarin-macios/pull/7539 which was fixed by
@dustin-wojciechowski has been landed.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
There are a few issues with the bindings, because the typedef `UITrait`
in the headers is defined like this:
```objective-c
typedef Class<UITraitDefinition> UITrait
```
which means: "A Class that implements the UITraitDefinition protocol",
and not "The UITraitDefinition" protocol", which is how it was bound.
This means the corresponding bindings are incorrect, so fix them. In
some cases it's not possible to fix the API, so new ones had to be
implemented in order to maintain backwards compatibility.
Fixes https://github.com/xamarin/xamarin-macios/issues/19410.
This commit adds some missing bindings and fixes up some of the previous
API that were incorrectly bound with Vector4 instead of Matrix4.
A sample app using some of these latest bindings can be found here:
https://github.com/haritha-mohan/vision-analyzer
Contributes to https://github.com/xamarin/maccore/issues/2719, though
the manual testing ended up not being necessary still helped catch a few
bugs and showcases some of the latest work done for this Xcode release.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This PR brings all the changes from the new Metal APIs. During the
review pay special attention to the changes done in the Protocols in
order to add tvOS support.
The main problem we have had doing this PR is that tvOS was not done on
time before the NET branching, that left us with a lot of memebers that
were NOT added in tvOS that are abstract on dotnet, which has left use
in a pickle.
Lets use the following code as an example.
Code found before this commit:
```csharp
[Mac (11, 0), iOS (14, 0), NoTV]
[MacCatalyst (14, 0)]
#if NET
[Abstract]
#endif
[Export ("accelerationStructureCommandEncoder")]
IMTLAccelerationStructureCommandEncoder CreateAccelerationStructureCommandEncoder ();
```
A naive approach would be to add just the tvOS suppor as follows:
```csharp
[Mac (11, 0), iOS (14, 0), TV (16,0)]
[MacCatalyst (14, 0)]
#if NET
[Abstract]
#endif
[Export ("accelerationStructureCommandEncoder")]
IMTLAccelerationStructureCommandEncoder CreateAccelerationStructureCommandEncoder ();
```
The above change represents and API braking change on the donet tvOS dll
because it adds a new Abstrtact members, so this is no an acceptable
solution.
There is a second naive approach we can take which is as follows:
```csharp
[Mac (11, 0), iOS (14, 0), TV (16,0)]
[MacCatalyst (14, 0)]
#if NET &!TVOS
[Abstract]
#endif
[Export ("accelerationStructureCommandEncoder")]
IMTLAccelerationStructureCommandEncoder CreateAccelerationStructureCommandEncoder ();
```
Yet again, the naive approach has an issue with it. In this case, all
the extension methods that are generated for tvOS (something the
generator writes when methods are not abstract) will be decorated with
availability attributes for all the other platforms, which is incorrect
and will make developers life worse.
That leaves us with the following approach:
```csharp
#if NET
#if !TVOS
[Mac (11, 0), iOS (14, 0), NoTV, MacCatalyst (14, 0)]
[Abstract]
#else
[NoMac, NoiOS, TV (16,0), NoMacCatalyst]
#endif
#else
[Mac (11, 0), iOS (14, 0), TV (16,0), MacCatalyst (14, 0)]
#endif
[Export ("accelerationStructureCommandEncoder")]
IMTLAccelerationStructureCommandEncoder CreateAccelerationStructureCommandEncoder ();
```
With the above change, we do not add an abstract method in tvOS and we
only add the tvOS abailabity attribute to the extension methods, and use
NoiOS etc for all the other platforms.
The change had to be done to ALL methods that added tvOS support. The
good news are that our cecil tests and our introspection tests catch the
two naive approaces :)
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Haritha Mohan <harithamohan@microsoft.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
Fixes this:
ObjCRuntime/Dlfcn.cs(102,20): warning CS0649: Field 'Dlfcn.Dl_info.dli_fbase' is never assigned to, and will always have its default value
ObjCRuntime/Dlfcn.cs(103,20): warning CS0649: Field 'Dlfcn.Dl_info.dli_sname' is never assigned to, and will always have its default value
ObjCRuntime/Dlfcn.cs(104,20): warning CS0649: Field 'Dlfcn.Dl_info.dli_saddr' is never assigned to, and will always have its default value
ObjCRuntime/Dlfcn.cs(101,20): warning CS0649: Field 'Dlfcn.Dl_info.dli_fname' is never assigned to, and will always have its default value
The warning is new, after we removed the referencing code from .NET in a recent commit.
WatchOS todo/xtro was weird, so added it to the ignore for now..all
intro tests look good though
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>