This will increase app size a little bit: the space for the MVID + 4 bytes for each
assembly, but we'll be able to validate and show a helpful error message if the generated
static registrar code does not match the assembly loaded at runtime.
It's also a step toward per-assembly static registration (ref: #12067).
This avoids one case where we we embed metadata tokens to a different assembly
in the generated static registrar code.
This is required for supporting per-assembly static registration
(https://github.com/xamarin/xamarin-macios/issues/12067).
* [xcode14] Bump to latest Xcode 14 Beta 5
* [CloudKit] Fix cloudkit intro on tvOS
* Revert "[Tests] Fix an monotouch-test test that landed broken. (#15503)"
This reverts commit 161de84bcf.
* Update tools/common/StaticRegistrar.cs
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* Fix typo
* [CHIP] Tell our drivers to not link CHIP at all
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Otherwise the P/Invoke generator leaves partial results in the static
registrar class, essentially saying things like "we've processed CoreMidi, no
need to add an #include for this framework", and then we'd generate the static
registrar code and that code would lack the #include for CoreMidi.
Finishing the P/Invoke generator output will clear out any state stored in the
static registrar.
Also fix a few other issues to make the generated P/Invoke wrapper code work,
and add a test.
Fixes https://github.com/xamarin/xamarin-macios/issues/15190.
We already have a few attributes that can specify the native name for a type, whenever the native name doesn't match the managed name:
* [Register ("DifferentClassName"): specifies the Objective-C class name
* [Native ("DifferentEnumName")]: specifies the Objective-C enum name (and also that it's a native-sized enum)
* [Protocol ("DifferentProtocolName")]: specifies the Objective-C protocol name
* [Category ("DifferentCategoryName")]: specifies the Objective-C category name
Unfortunately this leaves (at least) two cracks:
* Objective-C structs.
* Objective-C enums which aren't native-sized.
So I'm adding a [NativeName] attribute for this purpose, and updating numerous
types to specify the native name (either using an existing [Native] attribute
for enums that already have one, or by adding a new [NativeName] attribute).
The static registrar needs to know the native name for such types, in case
they appear as parameter types in function signatures.
This also allows us to simplify xtro a bit, to not have a separate map of
managed name given a native name, because we can now build that map
dynamically.
Fix lookup of block proxy attributes to look in protocols declared on base classes.
Broken pseudo code:
class BaseApplicationDelegate : NSObject, IUIApplicationDelegate {}
class MyApplicationDelegate : BaseApplicationDelegate {
[Export("application:didReceiveRemoteNotification:fetchCompletionHandler:")]
public void DidReceiveRemoteNotification (UIApplication application, NSDictionary userInfo, Action<UIBackgroundFetchResult> completionHandler) { }
}
the static registrar wouldn't figure out that the DidReceiveRemoteNotification method
comes from the UIApplicationDelegate, because it would only look in protocols defined
on MyApplicationDelegate, not any base classes.
The fix is to look in base classes too.
Also:
* Fix a boolean logic error when matching parameters between methods in another
(rarely used) code path when looking for matching binding methods in the extension
class for protocols with optional members.
* Add tests.
Fixes https://github.com/dotnet/maui/issues/6259.
We were trying to call the 'retain' and 'autorelease' selectors on objects
that weren't NSObjects when returning them from function calls. For some
unfathomable reason that has worked until now, but I started running into this
problem with other (unrelated) changes, so it needs to be fixed.
The fix is to not call the 'retain' and 'autorelease' selectors on
NativeObjects, instead call into managed code to either call the Retain method
on the managed NativeObject (if we're supposed to retain the return value), or
if we have to autorelease the return value, then check first if the input is
an NSObject, and only then call retain+autorelease.
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.
* 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
As a part of the breaking changes in .NET, we introduced a new type,
`ObjCRuntime.NativeHandle`, to represent native handles.
This meant that constructors taking taking `IntPtr handle`:
```cs
public class MyUIViewController : UIViewController {
protected MyUIViewController (IntPtr handle)
: base (handle)
{
}
}
```
would have to be ported to take `NativeHandle handle`:
```cs
public class MyUIViewController : UIViewController {
protected MyUIViewController (NativeHandle handle)
: base (handle)
{
}
}
```
The unfortunate part is that there will be no compiler warnings or errors
flagging this, so users won't know to do it unless they either read the
documentation (🤣) or run into the problem, googles for a while, runs into
someone else who had the same problem, and applies their (probably broken)
fix.
So we change our logic to:
1. Look for and use an `(IntPtr)` (or `(IntPtr, bool)`) constructor in .NET if
the `NativeHandle` version isn't found.
2. Show a warning.
3. Some time in the future maybe remove this hack/workaround.
Fixes https://github.com/xamarin/xamarin-macios/issues/14046.
* [tools] Extract the logic to parse OSPlatformAttribute platform names to a separate file/class.
* [introspection] Migrate .NET code to use the new .NET-style availability attributes.
This also means using the 'ApplePlatform' enum instead of the 'PlatformName'
enum, because the latter will be removed in .NET.
* [FileProvider] Exclude some deprecated API from .NET.
* [AVFoundation] Adjust availability attribute for AVCaptureStillImageOutput.HighResolutionStillImageOutputEnabled.
* Update tests.
* Stop using AvailabilityBaseAttribute, this type will disappear in .NET.
* Handle System.Runtime.Versioning.SupportedOSPlatformAttribute instead of our own availability attributes for .NET.
* Add tests (somewhat hacked together, but they work).
* [iAd] Remove this framework from .NET.
* [src] Use a different response file with HAS_<framework> defines for .NET.
This allows us to have different HAS_<framework> values for the .NET build (to
take into account frameworks that has been removed).
* Make the .NET framework removal logic per-platform.
* Use a different pattern in the rule to not match another pattern rule.
The QTKit framework does not exist on macOS anymore, so just remove our
bindings for it now that we can break compatibility.
Fixes a lot of errors like this when building with XAMCORE_4_0:
> build/dotnet/macos/generated-sources/Accessibility/AXCategoricalDataAxisDescriptor.g.cs(14,7): error CS0246: The type or namespace name 'QTKit' could not be found (are you missing a using directive or an assembly reference?)
> build/dotnet/macos/generated-sources/Accessibility/AXChart.g.cs(14,7): error CS0246: The type or namespace name 'QTKit' could not be found (are you missing a using directive or an assembly reference?)
> build/dotnet/macos/generated-sources/Accessibility/AXChartDescriptor.g.cs(14,7): error CS0246: The type or namespace name 'QTKit' could not be found (are you missing a using directive or an assembly reference?)
> build/dotnet/macos/generated-sources/Accessibility/AXChartDescriptorContentDirection.g.cs(14,7): error CS0246: The type or namespace name 'QTKit' could not be found (are you missing a using directive or an assembly reference?)
> build/dotnet/macos/generated-sources/Accessibility/AXCustomContent.g.cs(14,7): error CS0246: The type or namespace name 'QTKit' could not be found (are you missing a using directive or an assembly reference?)
> build/dotnet/macos/generated-sources/Accessibility/AXCustomContentImportance.g.cs(14,7): error CS0246: The type or namespace name 'QTKit' could not be found (are you missing a using directive or an assembly reference?)
> [...]
* [generator] Use '[U]IntPtr' in the P/Invoke signature for native enums.
* Use '[U]IntPtr' as the parameter type in the P/Invoke signature for native enum
parameters.
* Use '[U]IntPtr' in the P/Invoke method name for native enum parameters.
* Add an explicit conversion from UIntPtr to nuint (like we already have from IntPtr
to nint).
This makes the code identical between .NET and legacy Xamarin when using C# n[u]ints,
because those are really [U]IntPtrs.
* Use IntPtr/UIntPtr for all nint/nuint types in P/Invokes, not only native enums.
* Add a few more casts
Fixes these generator tests:
* GeneratorTests.BGenTests.FieldEnumTests
* GeneratorTests.BGenTests.NativeEnum
* [registrar] Handle UIntPtr like we do IntPtr.
Fixes this error in numerous tests:
error MT4169: Failed to generate a P/Invoke wrapper for objc_msgSend(System.IntPtr,System.IntPtr): The registrar cannot build a signature for type `System.Void' in method `ObjCRuntime.Messaging.objc_msgSend`.
* [NativeTypes] Make IntPtr and UIntPtr behave the same.
This fixes an issue where the linked output for a 32-bit mscorlib.dll and a
64-bit mscorlib.dll would be different, because different explicit operators
for UIntPtr would be kept.
The fix works because the conversion operators for nuint will not use
UIntPtr's explicit conversion operators anymore, it will just operate on plain
memory instead.
The deadlock goes like this:
1. Thread A holds the framework_peer_release_lock lock, and tries to lock the
refcount_mutex lock.
2. Thread B holds the refcount_mutex, and is waiting for the GC to complete
3. Thread C is trying to lock the framework_peer_release_lock while running
the GC.
The fix is in thread A, by not doing anything at all with the
framework_peer_release_lock lock locked.
The code contains extensive comments explaining the situation and the solution.
Fixes https://github.com/xamarin/xamarin-macios/issues/13066.
Co-authored-by: Chris Hamons <chris.hamons@xamarin.com>
* Bump maccore.
New commits in xamarin/maccore:
* xamarin/maccore@9acbbed1f6 [mlaunch] Add support for Xcode 13 beta 1. (#2452)
* xamarin/maccore@e48f75c0b6 [Xamarin.Hosting] Fix the --stdout arg not being forwarded to DeviceLaunchConfig (#2435)
* xamarin/maccore@109c695b1b [Xamarin.Hosting] Fix help string for launchdev argument (#2429)
Diff: cddbd1915d..9acbbed1f6
* [xtro] Fix generation of .pch files
* [xtro] Fix deprecated check to handle (anonymous) declarations and enable latest C# syntax in project
* [xtro] Fix _sanity_ checks
* [xtro] Update todo for beta 1
* [Siminstaller] Force siminstaller to use the xcode 12.5 url
Related issue: https://github.com/xamarin/xamarin-macios/issues/11881
* Fix introspection failures (due to [breaking] changes)
* [tests][intro] Fix hang for tvOS
Creating an instance of `NSMetadataQuery` hangs the simulator.
Even after (xharness) timeout the simulator is not in a good state
to run further tests and every new (tvOS) test will also hang...
* [tests][intro] Same hang for watchOS
except that further test execution does not seem affected (like tvOS)
```
CoreSimulator 772.1 - Device: Apple Watch Series 3 - 38mm (watchOS 8.0) - created by XHarness (42262867-E060-40C0-803E-6DA676AF50CC) - Runtime: watchOS 8.0 (19R5266p) - DeviceType: Apple Watch Series 3 - 38mm
Thread 0 Crashed:: tid_103 Dispatch queue: com.apple.main-thread
0 com.apple.Foundation 0x00007fff21470bd0 -[NSMetadataQuery dealloc] + 432
1 libobjc.A.dylib 0x00007fff200d11f7 objc_object::sidetable_release(bool, bool) + 177
2 com.apple.Foundation 0x00007fff21470a03 -[NSMetadataQuery init] + 64
3 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107efc139 xamarin_dyn_objc_msgSend + 217 (trampolines-x86_64-objc_msgSend.s:15)
4 ??? 0x000000010c76d4f6 0 + 4504081654
5 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107cffc85 mono_jit_runtime_invoke + 1621 (mini-runtime.c:3197)
6 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107e177d8 do_runtime_invoke + 54 (object.c:3052) [inlined]
7 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107e177d8 mono_runtime_invoke_checked + 136 (object.c:3220)
8 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107e1e3c5 mono_runtime_try_invoke_array + 2101 (object.c:5601)
9 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107daf977 ves_icall_InternalInvoke + 871 (icall.c:3927)
10 com.xamarin.introspection_watch.watchkitapp.watchkitextension 0x0000000107dc0167 ves_icall_InternalInvoke_raw + 103 (icall-def.h:667)
11 ??? 0x000000010a232799 0 + 4465043353
12 ??? 0x000000010c76e08b 0 + 4504084619
```
* [tests][monotouch-test] Fix failures with xcode 13 beta 1
* [tests][mmptest] Use a FAT framework that's build with x86_64 and arm64
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* If the return value from xamarin_get_reflection_method_method is cached in a
static variable, we can only release at process exist.
* Otherwise just release at the end of the current method.
Before:
There were 258096 MonoObjects created, 246948 MonoObjects freed, so 11148 were not freed. (dynamic registrar)
There were 205834 MonoObjects created, 205214 MonoObjects freed, so 620 were not freed. (static registrar)
After:
There were 258092 MonoObjects created, 246945 MonoObjects freed, so 11147 were not freed. (dynamic registrar)
There were 205834 MonoObjects created, 205600 MonoObjects freed, so 234 were not freed. (static registrar)
Before:
There were 258046 MonoObjects created, 235142 MonoObjects freed, so 22904 were not freed. (dynamic registrar)
There were 205804 MonoObjects created, 204193 MonoObjects freed, so 1611 were not freed. (static registrar)
After:
There were 258054 MonoObjects created, 235172 MonoObjects freed, so 22882 were not freed. (dynamic registrar)
There were 205804 MonoObjects created, 205190 MonoObjects freed, so 614 were not freed. (static registrar)
This fixes a memory corruption where we'd try to process out parameters when
an exception had occurred, and those out parameters weren't expected to be
processed.
Before:
There were 258046 MonoObjects created, 235142 MonoObjects freed, so 22904 were not freed. (dynamic registrar)
There were 205804 MonoObjects created, 204193 MonoObjects freed, so 1611 were not freed. (static registrar)
After:
There were 258018 MonoObjects created, 235128 MonoObjects freed, so 22890 were not freed. (dynamic registrar)
There were 205809 MonoObjects created, 204221 MonoObjects freed, so 1588 were not freed. (static registrar)
This involves storing the out parameter in an additional variable, so that we
can still access it after the method call.
Before:
There were 257927 MonoObjects created, 235060 MonoObjects freed, so 22867 were not freed. (dynamic registrar)
There were 205700 MonoObjects created, 203983 MonoObjects freed, so 1717 were not freed. (static registrar)
After:
There were 257935 MonoObjects created, 235064 MonoObjects freed, so 22871 were not freed. (dynamic registrar)
There were 205700 MonoObjects created, 204006 MonoObjects freed, so 1694 were not freed. (static registrar)
Before:
> There were 205700 MonoObjects created, 113865 MonoObjects freed, so 91835 were not freed. (static registrar)
After:
> There were 205700 MonoObjects created, 113982 MonoObjects freed, so 91718 were not freed. (static registrar)
* Implement our xamarin_dyn_objc_msgSend[Super] overrides for ARM64.
* Modify mmp to use those overrides.
* Fix an issue with the existing xamarin_arm64_common_trampoline that caused
exceptions to not unwind correctly.
* Add an ARM64 variation of xammac tests in xharness.
* Various test fixes.