Calling the direct functions instead of sending messages is slightly faster,
and additionally it may make some static analyzers think we've enabled ARC for
our Objective-C code (which we don't, because we need to manually manage
reference counting).
These direct functions aren't in any public header (they're in a private header),
but they're documented as part of ARC here: https://clang.llvm.org/docs/AutomaticReferenceCounting.html#runtime-support,
and clang emits references to these methods from user code, so it should be safe for us to use them.
Fixes https://github.com/xamarin/xamarin-macios/issues/19413.
Fixed an issue where the C# class name was coming in with `,
AssemblyName` tacked on the end.
Fixed an issue where a class that had an entry in the map didn't have a
`class_ptr` which was causing an NRE.
Fixed a predicate for deciding when to mark the assembly for save.
Note - for an as yet undetermined reason, the linker is not picking up
that I'm marking the assembly for save, which is why the `true` test
cases are commented out.
This fixes issue 16671 https://github.com/xamarin/xamarin-macios/issues/16671
We're going to change the pack names to support multi-targeting, so ahead
of the pack name change I'm changing the existing logic to use a variable
for the pack name in most places (this will make the rename much easier and
simpler).
These changes should have no effect by themselves.
Since NativeAOT generates native libraries and executables that do not
rely on assemblies they were compiled from, all managed assemblies can
be excluded from the application bundle.
This reduces the size of the application bundle by `3,17Mb` (or ~19%
compared to the baseline)
| MAUI ios app | Base | This PR | diff (%) |
|--------------|-----------|-----------|----------|
| SOD (Mb) | 50,13 | 41,93 | -16,3% |
| .ipa (Mb) | 16,59 | 13,43 | -19% |
Fixes: https://github.com/xamarin/xamarin-macios/issues/18472
Change all null checking expressions to use 'is null' and 'is not null'
instead of '== null' and '!= null'.
This was mostly done with sed, so code can probably be improved in many
other ways with manual inspection, but that will come over time.
Also add code to the autoformat script to automatically fix these issues in the future.
The timeout can be given:
* By setting the __XAMARIN_DEBUG_CONNECT_TIMEOUT__ environment variable for the app when launching it.
* By passing the XamarinDebugConnectTimeout MSBuild property to 'dotnet run' or 'dotnet build /t:Run'.
* By setting the IOSDebugConnectTimeout MSBuild property at build time.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1778177.
This makes it possible to simplify and remove a good chunk of related code.
Especially for CoreCLR this should be a minor perf improvement, because we'll do fewer transitions between managed and native code.
If we're creating a universal app, and here are satellite assemblies that are not
identical across all RuntimeIdentifiers, those assemblies will be stored in a RuntimeIdentifier-specific
subdirectory during the build.
Unfortunately we didn't know how to find those assemblies at runtime, causing localizations
in universal apps to not work.
This change will:
* Add support for looking in the directory where RID-specific satellite assemblies
are stored.
* Add an assembly resolution event handler to our CoreCLR bridge so that we can
execute our custom lookup code.
* Add an assembly resource lookup test to monotouch-test.
* Add a macOS + Mac Catalyst variation of monotouch-test to xharness that triggers
the bug (a universal test app).
Fixes https://github.com/xamarin/xamarin-macios/issues/16847.
Use function pointers to our managed callbacks instead of delegates for the native->managed bridge. This makes execution faster on AOT (because the AOT compiler can just emit the native function address, no need to go through the expensive marshalling machinery).
This involved a few changes to make the managed callbacks only use blittable types in the function signature:
* Use `sbyte` / `int8_t` instead of `bool`.
* Use pointers instead of `out`/`ref` arguments.
* Use `IntPtr` instead of `string` arguments.
The code rarely shows up in timing profiles before the change, and never after. This means that time-wise this doesn't save all that much, because there wasn't much to gain to begin with (but it's still a gain).
Memory-wise, we're now allocation 0,19 MiB less on startup (17,61 MiB vs 17,42 MiB).
MonoVM in .NET 6+ supports automatic autorelease pools on threadpool threads
just like CoreCLR does, so we can remove our custom mono profiler hooks to
accomplish this.
Fixes https://github.com/xamarin/xamarin-macios/issues/11788.
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).
Wrap the call to UIApplicationMain in a @try/@catch handler, and convert any
Objective-C exceptions to a managed exception.
This way the managed Main method (which calls UIApplication.Main) will be able
to catch any Objective-C exceptions.
It's fairly frequent (due to various types of coding errors) to have the
call to '[self release]' in xamarin_release_managed_ref crash. These
crashes are typically very hard to diagnose, because it can be hard to
figure out which object caused the crash. So now we store the native
object in a static variable, so that it can be read using lldb from a core
dump.
Ref: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1481312.
Allow code like this
```csharp
[DllImport(Constants.ObjectiveCLibrary, EntryPoint = "objc_msgSendSuper")
static extern IntPtr IntPtr_objc_msgSendSuper(IntPtr receiver, IntPtr selector);
[DllImport(Constants.ObjectiveCLibrary, EntryPoint = "objc_msgSendSuper")]
static extern void void_objc_msgSendSuper(IntPtr receiver, IntPtr selector, IntPtr arg);
[Export("selectedTextRange")]
public new IntPtr SelectedTextRange
{
get { return IntPtr_objc_msgSendSuper(SuperHandle, Selector.GetHandle("selectedTextRange")); }
set => void_objc_msgSendSuper(SuperHandle, Selector.GetHandle("setSelectedTextRange:"), value);
}
```
to work on the dynamic registrar since it already work with the static one.
This allows the simulators (which defaults to dynamic) to share the same code which is useful for implementing a workaround for related issue #15677.
There's a bug in the Mono runtime where the interpreter does not disable optimizations when the debugger is attached, which leads to the interpreter optimizing code and the debugger ending up rather confused.
The bug is fixed in the Mono runtime (https://github.com/dotnet/runtime/pull/71436), but there's no immediate way for the runtime to release this fix, so here we're implementing a workaround that disables interpreter optimizations if the debugging is enabled. It's somewhat clunky because the Mono external API wasn't designed for this, so we have to abuse the API a bit to accomplish the effect we want.
This is somewhat risky (since we're changing the startup path in a pretty big way), but there's an escape hatch via an environment variable, and also the workaround will not be in effect for release builds.
While the runtime issue exists in legacy mono/mono as well, we'll fix the Mono runtime for legacy, because we don't have to wait to consume legacy mono (https://github.com/xamarin/xamarin-macios/pull/15507). This means that the workaround is for .NET scenarios only.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
In the following scenario:
* Objective-C exception mode is to throw a managed exception.
* The xamarin_process_nsexception_using_mode was given a pointer to store any
resulting exceptions.
* The Objective-C exception didn't already have an associated managed exception.
We'd throw the managed exception upon return to managed code instead of
returning the managed exception.
With this change the xamarin_process_nsexception_using_mode will always return
the resulting managed exception in the scenario above (this way the behavior
is identical independent of whether the Objective-C exception already has an
associated managed exception or not).