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.
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.
The registrar removal was fixed recently but the test was still failing.
Turns out xharness modify the linker setting for this test (as the
linker is required for this optimization) but the newer dotnet csproj
did not have an entry (to modify).
Fixes https://github.com/xamarin/xamarin-macios/issues/10512
[xharness] Fix monotouch-test build when LinkSdk is used for dotnet projects
Skip failing assertion, issue filled
* Make 'throw Objective-C exception' the default for managed exception marshalling.
* Make 'throw managed exception' the default for Objective-C exception marshalling.
* Disallow the 'unwind through native frames' option: CoreCLR won't do it.
* Disallow the 'unwind through managed frames' option: it's the safeset
option by far, and also matches the reverse case.
* Disallow the 'disable' option: this is also not safe, let's try to go the
safe route with CoreCLR.
* Change the default in native code too.
Partial fix for #10940.
This makes it easier for CoreCLR. Also, at least for CoreCLR, it's unlikely to
be slower, since we'd have to compute the MONO_TYPE_* value in any
compatibility function.
Passing a 'MonoObject*' to a function that expects a GCHandle doesn't quite
work, so make sure to get a GCHandle for the exception we want to print
information about.
There are a number of tests that do not work on VMs yet our older
machines are using virtualization. Ignore those tests since we cannot
assert if they work or not.
fixes: https://github.com/xamarin/maccore/issues/2438
We need additional API in CoreCLR to support pending exception properly, and
this is in progress [1]. In the meantime, stub out parts of it, so that the
process doesn't abort. This way we'll have failing tests instead (and work in
other areas can progress, since the process doesn't abort).
[1]: https://github.com/dotnet/runtime/pull/52146
This is not the fastest implementation, but it's the simplest I could come up
with, with the target of sharing as much code as possible with MonoVM. It can
be improved later if we find out it's a slow path (these functions are not in
a common code path, very few API bindings end up here).
Internally the generator uses `AvailabilityBaseAttribute` to make its
decisions. For `dotnet` we generated the newer `[SupportedOSPlatform]`
and `[UnsupportedOSPlatform]`.
A 3rd-party (dotnet) binding might refer to members decorated with the
newer attributes and fail the build with an error [1]. Avoiding the error
is easy (first block of the diff) but it does not make the _right_
decisions (e.g. if a member is unavailable for the platform) when
generating the code.
To fix this we need to be able to convert the new attributes into the
well know `AvailabilityBaseAttribute` subclasses. We have not spotted
such cases yet because
* the bindings pass our tests (good but extra code would not fail)
* API diff across legacy and dotnet is not yet done [2]
[1] https://github.com/xamarin/xamarin-macios/issues/11497
[2] https://github.com/xamarin/xamarin-macios/issues/10210
Add stage names to the templates to use them in triggers in the future.
Remove a yaml file that turned out not to be needed (via a hack around
vsts limitations).
We need additional API in CoreCLR to support toggle refs properly, and this is
in progress [1]. In the meantime, stub out parts of it, so that the process
doesn't abort. This way we'll have failing tests instead (and work in other
areas can progress, since the process doesn't abort).
[1]: https://github.com/dotnet/runtime/pull/52146
* Update to new linker custom steps API
* PR feedback
- Fix indentation
- Add Initialize(LinkContext) to ExceptionalMarkHandler
- Remove unnecessary ifdef
- Use IsSetter/IsGetter
- Use [0] instead of Single()
- Avoid allocating empty collections
* Note override issue
* Clean up comments
* Move `DynamicRegistrationSupported` change earlier, along with the
detection code.
This solve the issue that `ILLink` does a similar job _before_ we have
the chance to disable the dynamic registrar.
* ILLink does not support considering other attributes as `[Preserve]`
when it is itself preserved at the assembly-level.
This ignored test is checking that feature so it cannot be enabled
for `NET`
Added to known breaking changes https://github.com/xamarin/xamarin-macios/issues/8900
* Fix removal of the dynamic registrar on legacy
* Fix IntPtr size inlining
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
* 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.
Rolf Bjarne Kvinge
Sebastien Pouliot
Manuel de la Pena
TJ Lambert
Sven Boemer