When we implemented support for using default interface members for binding protocols, we also unintentionally introduced a size regression. This happened because we now tell the linker to keep all methods in a protocol interface, thus all the corresponding types end up marked as well, etc.
This had an additional side effect: depending on the types that weren't linked away anymore, the App Store could flag an app, saying that additional entitlements is needed. This is what's happening in #21002: the App Store detects that the app references the `application:didRegisterForRemoteNotificationsWithDeviceToken:` selector [1] (from the method `RegisteredForRemoteNotifications` on `IUIApplicationDelegate`) and tells the developer they probably need the push notification entitlement.
The good news is that we don't need these protocol interface methods at runtime if the optimization to register protocols with the static registrar is enabled (which it is by default).
In this PR I teach the optimizer to remove the DynamicDependency attributes keeping these protocol interface methods from being trimmed out.
## Size improvements
* monotouch-test build for Release/ios-arm64 shrinks by [2.9mb (-2.6%)](https://gist.github.com/rolfbjarne/5e8ca6ea6854dc4a46f8e838dff11e6b)
* A very simple app (tests/dotnet/MySimpleApp) shrinks by [176kb (-0.3%)](https://gist.github.com/rolfbjarne/f0e062900528eb499fd96d124d18376f)
[1]: This is somewhat speculative, but it's probably not far from what the App Store actually does.
Fixes#21002.
## Description
As part of the fix for: https://github.com/dotnet/runtime/issues/99248
we disabled dedup optimization in partial/hybrid AOT mode (when both
interpreter and AOT compiler are enabled). This change got backported to
.NET 8 and with the latest servicing release regressed build times and
app sizes significantly as reported in:
https://github.com/xamarin/xamarin-macios/issues/20848
However, it turns out that disabling dedup optimization is not required
to fix https://github.com/dotnet/runtime/issues/99248 but instead we
should correct the Xamarin SDK integration with this optimization which
this PR is doing. The following section describes the initial problem in
more details.
## Overview of AOT modes and dedup optimization
When the repro project from
https://github.com/dotnet/runtime/issues/99248 is built with dedup
enabled in hybrid AOT+interpreter mode, the app crashes with:
```
024-07-23 14:32:37.524110+0200 IvansApp[12711:20244208] debug: AOT NOT FOUND: (wrapper other) object:gsharedvt_out_sig (intptr).
2024-07-23 14:32:37.524120+0200 IvansApp[12711:20244208] error: * Assertion at /Users/ivan/repos/runtime-mono-iOS/src/mono/mono/mini/interp/interp.c:2667, condition `is_ok (error)' not met, function:init_jit_call_info, Attempting to JIT compile method '(wrapper other) void object:gsharedvt_out_sig (intptr)' while running in aot-only mode. See https://learn.microsoft.com/xamarin/ios/internals/limitations for more information.
```
To track down why these wrappers which are used to transition from
interpreter to AOT code, are not generated we need to understand when
they are compiled in different AOT modes with and without dedup
optimization enabled:
- In full AOT setup - all assemblies AOT compiled
- `gsharedvt_out_sig` methods are never generated
- In hybrid AOT + interpreter setup - all assemblies AOT compiled:
`MtouchInterpreter=-all`
- Dedup OFF:
- `gsharedvt_out_sig` methods are generated in AOT images of every
assembly (to enable interpreter calling into each specific assembly -
here wrappers with same signatures are duplicated)
- Dedup ON:
- `gsharedvt_out_sig` methods are generated only in `aot-instances` AOT
image
- during AOT compilation of individual assemblies generation of
`gsharedvt_out_sig` is skipped
- during AOT compilation of `aot-instances` assembly we collect all
`gsharedvt_out_sig` variants from the full program scope and generate
code for them in `aot-instances` AOT image
- In hybrid AOT + interpreter setup - all assemblies interpreted except
a given assembly: `MtouchInterpreter=all,-MyAssembly`
- Dedup OFF:
- `gsharedvt_out_sig` methods are generated in AOT image of `MyAssembly`
(to enable interpreter calling into it)
- Dedup ON: <- $${\color{red} ISSUE }$$
- `gsharedvt_out_sig` methods *should* be generated only in
`aot-instances` AOT image, but the `aot-instances` image is missing
- explanation:
- what happens is that generation of `gsharedvt_out_sig` is skipped
during AOT compilation of `MyAssembly` (as expected).
- But, the build does not mark `aot-instances` assembly as the one that
should be AOT compiled.
- The reason for this is that we have a global `_IsDedupEnabled` flag,
but when custom linker step analysis `aot-instances.dll` it does not see
it as an assembly which should not be interpreted.
- To explain that better: we mark *all* assemblies as to be interpreted
(via: `MtouchInterpreter=all`), but exclude only `MyAssembly` (via:
`MtouchInterpreter=all,-MyAssembly`).
- So when custom linker step processes `aot-instaces.dll` it treats it
as an assembly to be interpreted, so it does not mark it for AOT
compilation.
- This further results with `aot-instances` AOT image missing, and all
the methods which we skipped during AOT compilation never get generated.
## The fix
To fix this and address regressions reported in:
https://github.com/xamarin/xamarin-macios/issues/20848 we are reenabling
dedup optimization whenever AOT compilation is requested and fixing the
issue where the custom linker step for generating AOT parameters always
treates the dedup assembly as the one to be AOTed.
Once approved this should be backported to .NET 8 as servicing releases
are also affected with it.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Ignore a few warnings by default, when reporting about types that we
couldn't register because they're deprecated/removed.
Also add a way to re-enable these warnings.
Fixes https://github.com/xamarin/xamarin-macios/issues/20670.
Add support for the LinkWithSwiftSystemLibraries metadata to specify whether a native library is a Swift library, in which case we'll automatically set the `LinkWithSwiftSystemLibraries` MSBuild property to `true`.
Also add a test.
Stop requiring a LinkWith attribute in an assembly in order to keep any Objective-C
types within. There are many ways to include a native library in a build nowadays,
and more and more often they don't need any LinkWith attributes to specify custom
linker behavior (in particular for frameworks, which can typically be included as-is).
The result of not searching such assemblies for Objective-C types would be that the
native linker would strip them away, and that would mean incorrect behavior at runtime.
However, this is a rather invasive change, especially for a minor release, so I'm
adding two things to make it better:
1. An opt-out MSBuild property: `RequireLinkWithAttributeForObjectiveCClassSearch`.
Set to 'true' to opt-out (default is 'false').
2. Improve handling of native symbols with regards to the native linker.
Add a new item group, ReferenceNativeSymbol, that contains native symbols
we handle in some way - either to be ignored or we ask the native linker
to keep it (by passing it as '-u ...' or in a symbol list file).
There are two supported types of metadata:
* SymbolType: either 'ObjectiveCClass', 'Function' or 'Field'. Used to
compute the complete native name of a symbol (for instance, the native
symbol for the Objective-C class "MyClass" is `_OBJC_CLASS_$_MyClass`,
while for a function "MyFunction" it's just `_MyFunction`.
* SymbolMode: either 'Ignore' or 'Default'. "Ignore" means to not pass the given
symbol to the native linker, the default is to do so.
SymbolType is required, while SymbolMode isn't.
Example symbol to keep:
```xml
<ItemGroup>
<ReferenceNativeSymbol Include="MyClass" SymbolType="ObjectiveCClass" />
</ItemGroup>
```
Example symbol to ignore:
```xml
<ItemGroup>
<ReferenceNativeSymbol Include="MyClass" SymbolType="ObjectiveCClass" SymbolMode="Ignore" />
</ItemGroup>
```
Finally use the latter solution to work around an issue that arouse with monotouch-test:
we reference an Objective-C class that doesn't exist in monotouch-test. This worked
because the referencing assembly didn't have a LinkWith attribute (and thus the reference
was ignored), but now that the reference isn't ignored anymore, we need to explicitly
ignore the Objective-C class.
* The 'Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100.Transport' dependency was renamed to 'Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100'
* Add a separate dependency for 'Microsoft.NET.ILLink', since it can have a different version than 'Microsoft.NET.ILLink.Tasks'.
* Update using the '.NET 8' and '.NET 8.0.1xx' channels.
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
There is an issue with managed static registrar and explicitly rooted
assemblies (through linker descriptor files) where the linker does not
emit the created module initializer.
This was originally reported in:
https://github.com/dotnet/runtime/issues/92106
and a smaller repro can be set up in: `tests/dotnet/MySingleView` test
project with the following changes:
### Smaller repro
1. Add a descriptor xml - `Roots.xml`
```xml
<linker>
<assembly fullname="MySingleView" preserve="All" />
</linker>
```
2. Include the root descriptor in the `MySingleView.csproj`
```xml
<ItemGroup>
<TrimmerRootDescriptor Condition="'$(_RootSelf)' == 'true'" Include="Roots.xml" />
</ItemGroup>
```
3. Publish/run the app on a device
```bash
dotnet publish -c Release -r ios-arm64 -p:PublishAot=true -p:PublishAotUsingRuntimePack=true -p:_RootSelf=true -t:Run /bl
```
4. The app crashes at start up with:
```
2023-09-25 18:55:42.562 MySingleView[477:55844] *** Terminating app due to uncaught exception 'ObjCRuntime.RuntimeException', reason: 'Can't register the class MySingleView.AppDelegate when the dynamic registrar has been linked away. (ObjCRuntime.RuntimeException)
at ObjCRuntime.Class.GetClassHandle(Type, Boolean, Boolean&) + 0x1c4
at UIKit.UIApplication.Main(String[], Type, Type) + 0x8c
at MySingleView!<BaseAddress>+0x2fae7c
'
```
NOTE: This is reported for NativeAOT but seems like a general problem
Additionally, here are the disassembled linked assemblies:
- regular:
https://gist.github.com/ivanpovazan/e82bdcb5313a846ff50de0a79d560553
- rooted:
https://gist.github.com/ivanpovazan/760e931fdcd3ef3e573d88087718dad2
It can be seen that the rooted one is missing:
```asm
// ================== GLOBAL METHODS =========================
.method private hidebysig specialname rtspecialname static
void .cctor() cil managed
{
// Code size 11 (0xb)
.maxstack 1
IL_0000: newobj instance void ObjCRuntime.__Registrar__::.ctor()
IL_0005: call void [Microsoft.iOS]ObjCRuntime.RegistrarHelper::Register(class [Microsoft.iOS]ObjCRuntime.IManagedRegistrar)
IL_000a: ret
} // end of global method .cctor
```
### The fix
This PR fixes this behaviour by explicitly marking module constructor to
prevent this from happening.
---
Fixes https://github.com/dotnet/runtime/issues/92106
This PR implements a workaround for the following build warning:
```
ILC: Method '[Microsoft.iOS]Foundation.NSObject.RegisterToggleRef(NSObject,native int,bool)' will always throw because:
Invalid IL or CLR metadata in 'Void Foundation.NSObject.RegisterToggleRef(Foundation.NSObject, IntPtr, Boolean)'
```
Ref #18524
`None` seems to be equivalent to not having the attribute at all. The type will be stripped by ILLink and ILC. The `PublicConstructors | NonPublicConstructors` seems to be a better option to keep the type while making it possible to trim as much of its members as possible.
This change resolves two warnings:
```
ILLink : warning IL2037: <Module>..cctor(): No members were resolved for 'None' on type 'Microsoft.Maui.Controls.Handlers.Compatibility.FrameRenderer.FrameView'.
ILC : warning IL2037: <Module>..cctor(): No members were resolved for '0' on type 'Microsoft.Maui.Controls.Handlers.Compatibility.FrameRenderer.FrameView'.
```
(Note: these warnings will still be present for _static_ classes which don't have a static constructor)
@rolfbjarne I believe we don't need https://github.com/dotnet/runtime/pull/90154 anymore
---------
Co-authored-by: Simon Rozsival <simon@rozsival.com>
This is a follow-up to #18854
The code that we use to generate method signatures still isn't working
properly. Method signatures that contain constructed generic types are
incorrect (this is a problem for example for UIGestureRecognizer
subclasses in MAUI). We are also handling multidimensional arrays
incorrectly.
Instead of implementing the signature builder ourselves, we can utilize
the `DocCommentId.GetDocCommentId (member)` method from
Mono.Cecil.Rocks.
```c#
void Method(IEnumerable<int> arg) { }
// before
[DynamicDependency ("Method(System.Collections.Generic.IEnumerable`1<System.Int32>)", typeof (MyClass))]
// after
[DynamicDependency ("Method(System.Collections.Generic.IEnumerable{System.Int32})", typeof (MyClass))]
```
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.
I noticed that we're generating invalid DynamicDependency attributes for generic types and methods. For example for the `void Activated(T sender)` method of `UIKit.UIGestureRecognizer.Callback<T>`:
```c#
// before:
[DynamicDependency("Activated(T)", typeof(UIKit.UIGestureRecognizer.Callback<>))]
// after:
[DynamicDependency("Activated(`0)", "UIKit.UIGestureRecognizer.Callback`1", "Microsoft.MacCatalyst")]
```
---------
Co-authored-by: Simon Rozsival <simon@rozsival.com>
This is a follow-up to #18666
This PR resolves the following warnings that I've seen in build logs
when running MySingleView with NativeAOT:
```
ILLink : warning IL2034: <Module>..cctor(): The 'DynamicDependencyAttribute' could not be analyzed. [/..../xamarin/xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj]
ILLink : warning IL2034: <Module>..cctor(): The 'DynamicDependencyAttribute' could not be analyzed. [/..../xamarin/xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj]
...
```
The generated module cctor code looks like this:
```c#
internal class <Module>
{
[DynamicDependency("InvokeConformsToProtocol(ObjCRuntime.NativeHandle)", typeof(NSObject))]
[DynamicDependency("Foundation.NSObject", null)]
[DynamicDependency("ConformsToProtocol(ObjCRuntime.NativeHandle)", typeof(NSObject))]
[DynamicDependency("Foundation.NSObject", null)]
// ...
static <Module>()
{
// ...
}
}
```
The `[DynamicDependency("T", null)]` attributes are invalid. We could
change them to `[DynamicDependency(DynamicallyAccessedMemberTypes.None,
typeof(T))]` but I think that attribute is redundant because the type
itself is always already preserved through the attribute that precedes
it with a selector of one of its methods/fields.
This is a follow-up to #18666
The idea is to transform `[Preserve(Conditional = true)]` into
`[DynamicDependency(signature, type)]` on the static constructor of the
given type:
```c#
class MyClass {
[Preserve (Conditional = true)]
public void MyMethod () { }
// transformed into ...
[DynamicDependency ("MyMethod", typeof (MyClass))]
static MyClass() { /* either the existing cctor or a new empty cctor */ }
public void MyMethod () { }
}
```
Add partial support for the `[Preserve]` attribute for NativeAOT. This
is done by injecting an equivalent `[DynamicDependency]` attribute. The
partial support comes from the fact that there's no way to map a
conditional preserve attribute (`[Preserve (Conditional = true)]`) to a
`[DynamicDependency]` attribute, so we report a warning instead.
For non-conditional `[Preserve]` attributes, we'll now add a
`[DynamicDependency]` attribute to the assembly's module constructor for
the type/member in question, effectively rooting it.
This makes it possible to fully link all our test suites when NativeAOT
(otherwise NativeAOT would just link out all the tests, leaving the test
suites empty - and unfortunately green, so this was a rather accidental
discovery).
This is a bit non-obvious, but we later use the presence of such a
stored list to determine if we need to generate the __Registrar__ type in the
assembly.
The problem is that we need to generate the __Registrar__ type even if
no trampolines were created, because we use it for numerous other purposes
as well (type lookup for instance).
Fixes https://github.com/xamarin/xamarin-macios/issues/18570.
This PR adds lookup tables and factory methods for INativeObjects and
NSObjects. These generated methods allow us to create instances of these
objects without needing reflection.
Closes#18358.
We can determine the exact constructor to call when creating
INativeObject instances in the generated code, so do exactly that.
This avoids a lot of slow reflection, and also makes the constructor
call visible for any linkers.
This also fixes a compiler warnings:
> tools/common/Rewriter.cs(333,25): warning CS8604: Possible null
reference argument for parameter 'path1' in 'string Path.Combine(string
path1, string path2)'.
And make nullability warnings in dotnet-linker show up as errors to
prevent future introduction of nullability warnings.
Rolf Bjarne Kvinge
Ivan Povazan
Simon Rozsival
GitHub Actions Autoformatter
Steve Hawley
Filip Navara
Ivan Povazan