* 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.
* 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>
The newly extracted `RegistrarRemovalTrackingStep` can be used inside
`dotnet-linker` to remove the dynamic registrar (if not required by some
other code).
There's no general way to set a pending managed exception in CoreCLR (the
current plan is to support setting a pending managed exception for the
objc_msgSend family of functions). This means that the way we've implemented
custom wrappers that can handle Objective-C exceptions won't work, because
those wrappers currently tries to set a pending managed exception (which Mono
throws upon returning from the corresponding native wrapper function).
So rewrite this a bit: these custom wrappers now return a GCHandle with the
managed exception as an out parameter, and the calling managed code throws
that exception instead.
This also required adjusting a few API definitions to match how their wrapper
functions are defined.
Move the xamarin_create_managed_ref internal call to managed code, to ease things
with CoreCLR.
In order to preserve performance, this wasn't a straight forward port.
* monotouch_create_managed_ref used to detect if there already was a GCHandle for
a native object. To avoid a managed->native transition, this logic has now been
moved into the code that sets the GCHandle (the xamarinSetGCHandle🎏 / xamarin_set_gchandle_trampoline
code), and these methods return a value saying whether the GCHandle was set or
not.
* xamarin_create_gchandle will check the retain count to determine whether to create
a weak or a strong GCHandle for the managed object. In this particular case we
should never need to create a strong GCHandle, which means that we don't need to
check the retain count (saving a managed->native transition).
Using the new perftest (#11298), I get very similar numbers for both old code and new code: https://gist.github.com/rolfbjarne/e0fc2ae0f21da15062b4f051138679af (multiple runs). Sometimes the old code is faster, sometimes the new code is faster (although the old code tends to be the one who wins).
In any case there aren't any significant performance hits due to this change, so it should be good to go.
Makes this error show properly:
> error MM2301: The linker step 'Setup' failed during processing: This version of {0} requires the {1} {2} SDK (shipped with Xcode {3}). Either upgrade Xcode to get the required header files or use the dynamic registrar or set the managed linker behaviour to Link Platform or Link Framework SDKs Only in your project's Mac Build Options > Linker Behavior} (to try to avoid the new APIs).. String.Format failed! Arguments were: "Microsoft.macOS" "macOS" "11.3" "12.5". Please file an issue to report this incorrect error handling.
* [mtouch] It seems watchOS simulators can automatically choose the right architecture from fat apps.
So we can build a fat simulator app, and not depend on mlaunch copying in the
specific architecture at launch time.
A partial fix for https://github.com/xamarin/maccore/issues/2411.
* Bump maccore.
New commits in xamarin/maccore:
* xamarin/maccore@d11721f55e [Xamarin.Hosting] Xcode seems to have changed some logic with regards to getting the primary instruments server. (#2416)
* xamarin/maccore@d27297a098 [Xamarin.Hosting] Don't copy single-arch executable over a fat executable. (#2417)
* xamarin/maccore@6c305d4aa7 [Xamarin.Hosting] Launching may succeed even if the launch request fails. Don't fail in that case. (#2415)
* xamarin/maccore@bccc91d6a0 Support ARM64 and ARM64e simulators (#2418)
Diff: c89fd6a694..d11721f55e
In this case we can obsolete the attribute on both legacy and dotnet
since the replacement attribute is available on both. However this does
require a small update to the legacy linker (and is part of the PR).
Fix https://github.com/xamarin/xamarin-macios/issues/10674
* [build] Use arcade dependency management tooling
* Apply feedback
* Apply second round of feedback
* Always make dotnet.config before trying to read it
* Debugging
* Update dependencies, trim tabs and spaces
* [dotnet] Remove the existing workload shipped with .NET and install our locally built ones.
The new version of .NET ships with our workloads, but those aren't
the workloads we want to use, so replace them with our own.
* Update .gitignores.
* Bump to 6.0.100-preview.3.21181.5
That required renaming simulator runtime packs...
* More rename for simulator packages
* moar (hopefully all)
* Bump to 6.0.100-preview.3.21201.11
This fix the issue with `Wait` that failed several tests in monotouch-tests
However it does not include the fix for AppConext.GetData on device (AOT)
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Sebastien Pouliot <sebastien@xamarin.com>
Use a private property (prefixed with underscore) for now, until we can decide
on a better/general name.
Also add a variation to xharness to build monotouch-test with CoreCLR
(building works fine, but it crashes at startup, which is expected at this
point).
* Add configure option to disable building for legacy Xamarin.
This can greatly speed up the debug-edit-build cycle when doing .NET
development, since it cuts down the build time in half more or less.
* Bump maccore.
New commits in xamarin/maccore:
* xamarin/maccore@548fa45432 [mlaunch] Disable building mlaunch when not including the legacy Xamarin build. (#2403)
Diff: 0562e08b12..548fa45432
* [runtime] Build our runtime for Mac Catalyst/ARM64 for .NET.
* [ObjCRuntime] There's no need for the StartWWAN implementation on Mac Catalyst.
This also fixes a build error:
error MT5214: Native linking failed, undefined symbol: _xamarin_start_wwan. This symbol was referenced by the managed member ObjCRuntime.Runtime.xamarin_start_wwan.
* Only exclude xamarin_start_wwan in the .NET version of Mac Catalyst.
* [tests] Update to not run the StartWWAN test on Mac Catalyst.
* Update conditional logic.
* Fix build with newer make versions.
* Bump Xamarin.MacDev.
New commits in xamarin/Xamarin.MacDev:
* xamarin/Xamarin.MacDev@1e738e9 [Xamarin.MacDev] Extract the code to convert between Mac Catalyst versions to a separate file. (#89)
* xamarin/Xamarin.MacDev@a3bb12c [Xamarin.MacDev] Add methods to map between iOS and macOS versions for Mac Catalyst. (#88)
Diff: 02d6d05be3..1e738e9f7f
* [msbuild] Use the macOS SDK to build Mac Catalyst apps instead of the iOS SDK
From a native compilation perspective, compilating a Mac Catalyst is the macOS SDK
+ a dash of iOS, so use the native macOS SDK to compile, and then do the corresponding
adjustments elsewhere.
At the same time document which version we want for the sdk version and the deployment
target in mtouch, and adjust the code accordingly (sdk version: macOS version; deployment
target: iOS version).
* Update resource files
* Add new entry to canary test for string localization.
Today both `mtouch` and `mmp` are copying the entire `.framework`
directories inside the `.app\[Contents\]Frameworks\` directory.
However not everything in a framework is required at runtime. The most
common unrequired files would be headers (`Headers/*.h`) and modules
(`Modules/*`).
Looking at Xcode build output we can see something like:
```
builtin-copy -exclude .DS_Store -exclude CVS -exclude .svn -exclude .git -exclude .hg -exclude Headers -exclude PrivateHeaders -exclude Modules -exclude \*.tbd -bitcode-strip replace-with-marker -bitcode-strip-tool
```
which excludes a few more, less common, files.
This _builtin_ command is not available externally (for us to re-use)
but it hints that Xcode is likely using `rsync` to avoid copying part of
the files.
Note: the builtin command also _likely_ calls `bitcode_strip` too (or has
similar code embedded) and `mtouch` already does so too
There's a cost to spawning an external process, like `rsync`, which we
avoid by having our own file copier, which clones files (almost zero
cost). That does not support excluding files, but deleting files is also
very cheap. Testing shows copying a framework to be less than 1 ms, even
with with extra deletion step.
* Tweak `GetRealPath` to optionally not to warn if the path does not exists
since, in this case, it's a check we want to do after resolving the path
This fixes several (5) MTouch tests looking for specific (and no extra)
warnings
```
Unable to canonicalize the path '/Users/builder/azdo/_work/2/s/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory195/testApp.app/Frameworks/Mono.framework/CVS': No such file or directory (2).
```
because:
> If the file to be deleted does not exist, no exception is thrown.
https://docs.microsoft.com/en-us/dotnet/api/system.io.file.delete?view=net-5.0
and yes this is different from `Directory.Delete` and PR https://github.com/xamarin/xamarin-macios/pull/10441
* Fix MT0015 test failure
The MT0015 test creates a directory where a file is expected.
That's fine except the code for handling this was a bit weird. It
worked because of a `TryDelete` on the path, which avoided the
`UnauthorizedAccessException` when `File.Delete` is used on a path.
Then later there's a `Directory.Exists` check that would throw...
The code now does the `Directory.Exists` first and only call
`File.Delete` if it returns false. The throwing of the exception
is kept since the code (and test) are already present (and this
minimize changes and chance of other surprises)
* [tests] Build test-libraries for Mac Catalyst.
* [msbuild] Add support for Mac Catalyst binding projects.
* [mtouch] Allow frameworks for Mac Catalyst apps.
* [mtouch] Put frameworks in the expected location for Mac Catalyst apps.
* [msbuild] Create the Resources directory before trying to put files in it.
In some places we have to provide the macOS version, and in other places the
iOS version. Add a map and the corresponding code to convert between the two,
and use them when needed.
* Bumps mono binaries to include x86_64 watchOS support
* Build runtime/registrar x86_64 slices
* Produce a 64 bit version of Xamarin.WatchOS.dll
* Allow building x86_64 for watch simulators in mtouch
* Let xharness know about x86_64
* [tests] Add x86_64 arch to test-libraries
* Make dotnet package aware of x64
* [ObjCRuntime] Fix computing if we're calling a stret function or not in a 64-bit watchOS simulator.
* [xharness] Re-enable some watchOS tests.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
New commits in mono/mono:
* mono/mono@ac596375c7 Add support for OP_FCONV_TO_I to mini-arm64.c. (#20548)
* mono/mono@392fe5b87b [2020-02][watchOS] Add simwatch64 support (#20552)
* mono/mono@a22ed3f094 Fix potential crash for Encoder.Convert (#20522)
* mono/mono@970783731f Bump to F# 5.0 (#20511)
* mono/mono@32ab5066f7 Bump msbuild to fix a build issue
* mono/mono@93a7fe77e8 Ensure special static slots respect alignment. (#20506)
* mono/mono@3db5b35841 [debugger] Switch to GC Unsafe in signal handler callbacks (#20495)
* mono/mono@af315f44c4 [2020-02][corlib] ThreadAbortException protection for ArraySortHelper (#20468)
* mono/mono@ca11fb0fd8 [2020-02] Bump ikvm-fork to include https://github.com/mono/ikvm-fork/pull/20 (#20452)
Diff: be2226b5a1..ac596375c7
Rolf Bjarne Kvinge
TJ Lambert
Sven Boemer
Manuel de la Pena
Sebastien Pouliot
Peter Collins
Alex Soto
VS MobileTools Engineering Service 2