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.
Also add Call Frame Information (CFI) / Canonical Frame Address (CFA) directives.
This is required for native exceptions to work properly (otherwise the native runtime
won’t be able to unwind stack frames correctly).
There was a confusion between hex and decimal values, the values are written
using decimal in the headers, but were treated as hex values in the C# source.
This is a breaking change, but the values are just plain wrong, so I don't
really see a way around this. Also there's no good way to work around it by
accepting the old values and converting in our managed wrapper method, because
the old ARM values match the new PPC values, so there's no way to know if the
input is using old values or new values.
When using the MonoVM, we compare MonoClass instances by pointer. This turns
out a bit complicated for CoreCLR, because our MonoClass instances are not
unique (there can be multiple MonoClass instances that refer to the same
type), so instead implement helper methods that do the comparison. This also
has the benefit of not requiring any memory allocations on CoreCLR.
Adds a coherent parent dependency to `Microsoft.NET.ILLink.Tasks`, which
ensures that it will not be updated past the version included in
`Microsoft.Dotnet.Sdk.Internal`.
These changes allow us to remove our mono/linker darc subscriptions, as
`Microsoft.Dotnet.Sdk.Internal` updates will also bring in the latest
`Microsoft.NET.ILLink.Tasks` that the SDK references. This will reduce
the number of dependency update PRs created by maestro.
Since the `Microsoft.NET.ILLink.Tasks` and `Microsoft.NET.ILLink` NuGet
packages are created by the same build, we only need to track one of
these package IDs in eng/Version* files.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Rolf Bjarne Kvinge
TJ Lambert
Manuel de la Pena
Sebastien Pouliot
Sven Boemer
Peter Collins
Mauro Agnoletti