The debug code is removed only on release builds.
Unlike the _legacy_ linker the method itself is still present (not
removed) from the assembly - but it will be empty (no code).
Unit test was adapted to work under all conditions.
Fixes https://github.com/xamarin/xamarin-macios/issues/9613
* [catalyst][adsupport] Update xtro - framework is not available
also found out an API was removed by Apple... turned it into
a stub for compatibility.
We already define it in the generated code, so the native compiler shows a warning:
Microsoft.macOS.registrar.coreclr.x86_64.m:1:9: warning: 'CORECLR_RUNTIME' macro redefined [-Wmacro-redefined]
#define CORECLR_RUNTIME
^
<command line>:2:9: note: previous definition is here
#define CORECLR_RUNTIME 1
^
The native xamarin_bridge_get_method_declaring_type method and the
corresponding managed method (GetMethodDeclaringType) takes and returns a
MonoObject*, not a GCHandle.
Due to the wonders of void pointers, this worked just fine before - there's no
actual change to the compiled code - but the code is now more consistent and
less confusing.
Add changes to sync main into Localization branch
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
Co-authored-by: Connor Adsit <cadsit@microsoft.com>
Fixes this mmptest:
* Xamarin.ApiTest.ApiTest.AlwaysOptimizable(macOSMobile): All methods calling optimizable API must be optimizable
The method System.Boolean ObjCRuntime.Runtime::IsUserType(System.IntPtr) calls System.Boolean ObjCRuntime.Runtime::get_DynamicRegistrationSupported(), but it does not have a [BindingImpl (BindingImplOptions.Optimizable)] attribute.
* Xamarin.ApiTest.ApiTest.AlwaysOptimizable(macOSFull): All methods calling optimizable API must be optimizable
The method System.Boolean ObjCRuntime.Runtime::IsUserType(System.IntPtr) calls System.Boolean ObjCRuntime.Runtime::get_DynamicRegistrationSupported(), but it does not have a [BindingImpl (BindingImplOptions.Optimizable)] attribute.
The value should never be used if everything is working fine, but if something
is wrong, then this value will at least get consistent behavior.
The visible result for us right now is that monotouch-test will fail with a
test failure instead of crashing.
Also:
* Use the right arm64 runtime identifier depending on the target platform.
* Don't add CoreCLR variations of Mac Catalyst tests.
* Exclude UISearchDisplayController from tests, since it isn't available in
Mac Catalyst anymore.
When checking whether a type is a user type or not, we might have to do a
dynamic check if the dynamic registrar is available. Otherwise we may run into
a situation where the static registrar ran during the app build, but then the
app loaded additional assemblies at runtime, and those assemblies contained
user types that were registered using the dynamic registrar, so the static
registrar doesn't know about those custom types (in other words: we need to
check at runtime).
CoreCLR is being added for macOS only. We can eliminate a lot of recent
code additions (about half a megabyte in the past week) by eliminate code
branches under `if (IsCoreCLR)`.
Unlike handling (non required at runtime) custom attributes the
`ILLink.Substitutions.xml` will vary quite a bit across platforms so we
use a unique file for each platform.
If the task that creates the native object files doesn't execute (because the
native object files already exists and are up-to-date), the resulting list of
native object files to link will be empty.
This typically happens for a rebuild: if a native linker error occurs when
linking the main executable, building again will result in a successful build,
because we wouldn't try to link the main executable again.
The Xamarin.iOS.dll assembly may be required at runtime (for non-linked apps,
if they consume other libraries that reference Xamarin.iOS.dll), and only
implementation assemblies will be put in the app bundle, thus Xamarin.iOS.dll
must be an implementation assembly.
Due to incorrect update while adapting code for translations.
```
<data name="W0073" xml:space="preserve">
<value>The App Extension '{0}' has a CFBundleVersion ({1}) that does not match the main app bundle's CFBundleVersion ({2})
</value>
</data>
<data name="W0074" xml:space="preserve">
<value>The App Extension '{0}' has an unrecognized NSExtensionPointIdentifier value ('{1}').
</value>
</data>
```
Fixes https://github.com/xamarin/xamarin-macios/issues/11581
Instead of passing a pointer to pointer to a pointer of a MonoObject to
xamarin_mono_object_retain, we pass a pointer to a MonoObject (like
xamarin_mono_object_retain expects).
* CoreCLR doesn't support generic Action delegates in reverse (P/Invokes), so
we need to find a different solution.
* The native CGPDFOperatorTable callback API is not very friendly to us,
because we can't pass it callback-specific data, which means that the
managed caller must conform to the FullAOT requirement of the managed
callback (must be a static function; must have a MonoPInvokeCallback
attribute).
* We can leverage the new function pointer syntax in C# 9 to make these
requirements enforced by the C# compiler (unmanaged function pointer +
UnmanagedCallersOnly attribute). The resulting API is still clunky to use,
but I don't see any way around that.
Fixes this monotouch-test failure with CoreCLR:
[FAIL] Tamarin : System.Runtime.InteropServices.MarshalDirectiveException : Cannot marshal 'parameter #3': Non-blittable generic types cannot be marshaled.
at CoreGraphics.CGPDFOperatorTable.CGPDFOperatorTableSetCallback(IntPtr table, String name, Action`2 callback)
at CoreGraphics.CGPDFOperatorTable.SetCallback(String name, Action`2 callback)
at MonoTouchFixtures.CoreGraphics.PDFScannerTest.Tamarin() in xamarin-macios/tests/monotouch-test/CoreGraphics/PDFScannerTest.cs:line 102
Ref: https://github.com/dotnet/runtime/issues/32963
* Remove a few unused xamarin_get_*_class functions.
* Make the remaining two (xamarin_get_[nsnumber|nsvalue]_type) return a
MonoType* instead of MonoClass* - that makes things slightly simpler for
CoreCLR (the MonoClass* return values from the previous functions were
always converted to MonoType*s anyway).
* Implement the xamarin_get_[nsnumber|nsvalue]_type functions.
* Make the existing mono_get_string_class use the new (and more generic)
xamarin_bridge_lookup_class method instead of the specific
xamarin_bridge_get_string_class (which can now be removed).
If can happen that when we bump xcode we do not get an api & generator
diff. This results in a set of cascading events that make the build
fail.
We know track when the result is not 0, store it in a var and pass that
variable to all the tempaltes that need it. The pwsh script already has
an if to check if the file if present and if not, it shows a warning.
Manuel de la Pena
Sebastien Pouliot
Rolf Bjarne Kvinge
TJ Lambert