Because simulator is where we most commonly run tests.
And hardcode arm64 - if x64 is ever needed, and I'm bugged enough to add
auto-detection, I'll do it then.
There's both a Network.NWEndpoint and a NetworkExtension.NWEndpoint, and the
generator generates ambiguous code in certain cases.
Fix the generator to use the full type reference for such types.
There's a bug where the test variation to run introspection on older OS
versions doesn't properly exclude legacy Xamarin variations when legacy
Xamarin is disabled.
Since legacy Xamarin is dead, just remove introspection for legacy Xamarin
completely.
The 'nw_connection_set_viability_changed_handler' P/Invoke was originally
bound as 'SetBooleanChangeHandler', which isn't quite right.
So now bind it as 'SetViabilityChangeHandler', obsolete the old version and
remove it in XAMCORE_5_0.
Using RUNTIMEIDENTIFIER(S) in the Makefile interferes with the build, because
they get passed on to msbuild, which sees them as properties (RuntimeIdentifier(s)).
Thus use RID instead, and only pass on the value to the build if appropriate.
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.
* Forward [Obsolete] from api definition interfaces.
* Generate [EditorBrowsable] whenever an api definition member as either
[EditorBrowsable] or [Obsolete].
This pull request updates the following dependencies
## From https://github.com/dotnet/installer
- **Subscription**: 80cb9ffd-f92f-4fc8-9f8b-08dbca46abfb
- **Build**: 20240819.10
- **Date Produced**: August 19, 2024 9:04:53 PM UTC
- **Commit**: 6e9002c2efcfc09687feca31864ebc987c3c9ec8
- **Branch**: refs/heads/release/8.0.1xx
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 8.0.109-servicing.24416.1 to 8.0.109-servicing.24419.10][8]
[8]: 228439883b...6e9002c2ef
## Coherency Updates
The following updates ensure that dependencies with a *CoherentParentDependency*
attribute were produced in a build used as input to the parent dependency's build.
See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview)
- **Coherency Updates**:
- **Microsoft.NET.ILLink.Tasks**: from 8.0.7 to 8.0.8 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 8.0.7 to 8.0.8 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NETCore.App.Ref**: from 8.0.7 to 8.0.8 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100**: from 8.0.7 to 8.0.8 (parent: Microsoft.NETCore.App.Ref)
- **Microsoft.NETCore.App.Ref**: from 8.0.7 to 8.0.8 (parent: Microsoft.Dotnet.Sdk.Internal)
Note: there we no changes in beta 1, beta 2, beta 3, beta 4 or beta 6.
Additionally, none of the added APIs are APIs we'll bind for now,
they're rather specialized.
The capitalization of these new enum members matches the capitalization
of other MPEG* enum members in the same enum.
Note: there were no changes in beta 2, beta 4, beta 5 or beta 6.
Marked as a preview API, because this framework requires implementing a
user-space file system to validate anything, and that's a bit too much
at the moment.
Tentatively marking this for stable release in .NET 11.
Up-to-date until beta 6.
The bindings that have been removed haven't fully been removed from the
headers, but it looks like they will be soon. These bindings have also been
deprecated since before the earliest OS versions we support, so there should
be no need to keep them around.
Removing them preemptively also lessens the risk of running into App Store
rejections in the future.
A few tests changes were needed to ignore the newly obsoleted/hidden APIs.
Note: there were no changes in beta 2, beta 3, beta 4, beta 5 or beta 6.
Note: there were no changes in beta 2-6.
---------
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Backports the following maestro and artifact storage changes,
removing dependencies on bosstoragemirror and adding support
for passwordless maestro auth.
0d1bd7b1bcebf969ee402562461eeb
When we compute the signature of a block for Objective-C, we need to use
parameters of the user-provided callback (and not the intermediate
UnmanagedCallersOnly method) to compute the signature.
This is because the intermediate method's parameters don't have all the
information we need to correctly compute the block signature (in
particular for the issue in question, the user callback has an `NSError`
parameter, while the intermediate method has an `IntPtr` parameter, and
these two parameter types show up differently in the block signature).
This is solved by adding the `UserDelegateType` attribute (which was
created for exactly this, and it's just in older generated code) to the
intermediate method, pointing to a delegate with the correct managed
signature.
Fixes https://github.com/xamarin/xamarin-macios/issues/21008.
* Handle DllImports without an EntryPoint value correctly.
* Keep track of DllImports we've found separately, instead of removing entries
from the list of DllImports we found. This fixes an issue with native
functions that are declared more than once in the headers: we'd match the
first instance to the DllImport, and then report the second one as 'not
bound'.
The CustomizedCodeSigning test asserts that a certain condition shows a
particular error message from codesign.
There are multiple files in the app bundle that can trigger this particular
message, so change the logic to not assert on a particular file, instead use
assert on the remained of the error message.
Fixes this random test failure:
Xamarin.Tests.DotNetProjectTest.CustomizedCodeSigning(iOS,"ios-arm64"): Failure when comparing error messages:
Unexpected error message #0:
Expected: /usr/bin/codesign exited with code 1:\n/Users/builder/azdo/_work/4/s/xamarin-macios/tests/dotnet/CustomizedCodeSigning/iOS/bin/Debug/net9.0-ios/ios-arm64/CustomizedCodeSigning.app: replacing existing signature\n/Users/builder/azdo/_work/4/s/xamarin-macios/tests/dotnet/CustomizedCodeSigning/iOS/bin/Debug/net9.0-ios/ios-arm64/CustomizedCodeSigning.app: code object is not signed at all\nIn subcomponent: /Users/builder/azdo/_work/4/s/xamarin-macios/tests/dotnet/CustomizedCodeSigning/iOS/bin/Debug/net9.0-ios/ios-arm64/CustomizedCodeSigning.app/System.Diagnostics.DiagnosticSource.dll
Actual: /usr/bin/codesign exited with code 1:\n/Users/builder/azdo/_work/4/s/xamarin-macios/tests/dotnet/CustomizedCodeSigning/iOS/bin/Debug/net9.0-ios/ios-arm64/CustomizedCodeSigning.app: replacing existing signature\n/Users/builder/azdo/_work/4/s/xamarin-macios/tests/dotnet/CustomizedCodeSigning/iOS/bin/Debug/net9.0-ios/ios-arm64/CustomizedCodeSigning.app: code object is not signed at all\nIn subcomponent: /Users/builder/azdo/_work/4/s/xamarin-macios/tests/dotnet/CustomizedCodeSigning/iOS/bin/Debug/net9.0-ios/ios-arm64/CustomizedCodeSigning.app/System.Collections.NonGeneric.aotdata.arm64
Unexpected error message #1:
Expected: Failed to codesign '/Users/builder/azdo/_work/4/s/xamarin-macios/tests/dotnet/CustomizedCodeSigning/iOS/bin/Debug/net9.0-ios/ios-arm64/CustomizedCodeSigning.app': /Users/builder/azdo/_work/4/s/xamarin-macios/tests/dotnet/CustomizedCodeSigning/iOS/bin/Debug/net9.0-ios/ios-arm64/CustomizedCodeSigning.app: replacing existing signature\n/Users/builder/azdo/_work/4/s/xamarin-macios/tests/dotnet/CustomizedCodeSigning/iOS/bin/Debug/net9.0-ios/ios-arm64/CustomizedCodeSigning.app: code object is not signed at all\nIn subcomponent: /Users/builder/azdo/_work/4/s/xamarin-macios/tests/dotnet/CustomizedCodeSigning/iOS/bin/Debug/net9.0-ios/ios-arm64/CustomizedCodeSigning.app/System.Diagnostics.DiagnosticSource.dll
Actual: Failed to codesign '/Users/builder/azdo/_work/4/s/xamarin-macios/tests/dotnet/CustomizedCodeSigning/iOS/bin/Debug/net9.0-ios/ios-arm64/CustomizedCodeSigning.app': /Users/builder/azdo/_work/4/s/xamarin-macios/tests/dotnet/CustomizedCodeSigning/iOS/bin/Debug/net9.0-ios/ios-arm64/CustomizedCodeSigning.app: replacing existing signature\n/Users/builder/azdo/_work/4/s/xamarin-macios/tests/dotnet/CustomizedCodeSigning/iOS/bin/Debug/net9.0-ios/ios-arm64/CustomizedCodeSigning.app: code object is not signed at all\nIn subcomponent: /Users/builder/azdo/_work/4/s/xamarin-macios/tests/dotnet/CustomizedCodeSigning/iOS/bin/Debug/net9.0-ios/ios-arm64/CustomizedCodeSigning.app/System.Collections.NonGeneric.aotdata.arm64
All errors:
/usr/bin/codesign exited with code 1:
/Users/builder/azdo/_work/4/s/xamarin-macios/tests/dotnet/CustomizedCodeSigning/iOS/bin/Debug/net9.0-ios/ios-arm64/CustomizedCodeSigning.app: replacing existing signature
/Users/builder/azdo/_work/4/s/xamarin-macios/tests/dotnet/CustomizedCodeSigning/iOS/bin/Debug/net9.0-ios/ios-arm64/CustomizedCodeSigning.app: code object is not signed at all
In subcomponent: /Users/builder/azdo/_work/4/s/xamarin-macios/tests/dotnet/CustomizedCodeSigning/iOS/bin/Debug/net9.0-ios/ios-arm64/CustomizedCodeSigning.app/System.Collections.NonGeneric.aotdata.arm64
Failed to codesign '/Users/builder/azdo/_work/4/s/xamarin-macios/tests/dotnet/CustomizedCodeSigning/iOS/bin/Debug/net9.0-ios/ios-arm64/CustomizedCodeSigning.app': /Users/builder/azdo/_work/4/s/xamarin-macios/tests/dotnet/CustomizedCodeSigning/iOS/bin/Debug/net9.0-ios/ios-arm64/CustomizedCodeSigning.app: replacing existing signature
/Users/builder/azdo/_work/4/s/xamarin-macios/tests/dotnet/CustomizedCodeSigning/iOS/bin/Debug/net9.0-ios/ios-arm64/CustomizedCodeSigning.app: code object is not signed at all
In subcomponent: /Users/builder/azdo/_work/4/s/xamarin-macios/tests/dotnet/CustomizedCodeSigning/iOS/bin/Debug/net9.0-ios/ios-arm64/CustomizedCodeSigning.app/System.Collections.NonGeneric.aotdata.arm64
---------
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
This pull request updates the following dependencies
## Coherency Updates
The following updates ensure that dependencies with a *CoherentParentDependency*
attribute were produced in a build used as input to the parent dependency's build.
See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview)
- **Coherency Updates**:
- **Microsoft.NET.ILLink.Tasks**: from 9.0.0-rc.1.24406.14 to 9.0.0-rc.1.24408.12 (parent: Microsoft.NET.Sdk)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-rc.1.24406.14 to 9.0.0-rc.1.24408.12 (parent: Microsoft.NET.Sdk)
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport**: from 9.0.0-rc.1.24379.5 to 9.0.0-rc.1.24402.2 (parent: Microsoft.NETCore.App.Ref)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-rc.1.24406.14 to 9.0.0-rc.1.24408.12 (parent: Microsoft.NET.Sdk)
## From https://github.com/dotnet/sdk
- **Subscription**: 3727984b-7a79-4ba3-37dd-08dbe6bddf31
- **Build**: 20240809.1
- **Date Produced**: August 9, 2024 8:31:14 AM UTC
- **Commit**: 43360291a50c9c7c471551f8f8363919d38014ea
- **Branch**: refs/heads/main
- **Updates**:
- **Microsoft.NET.Sdk**: [from 9.0.100-rc.1.24408.2 to 9.0.100-rc.1.24409.1][9]
- **Microsoft.NET.ILLink.Tasks**: [from 9.0.0-rc.1.24406.14 to 9.0.0-rc.1.24408.12][10]
- **Microsoft.NETCore.App.Ref**: [from 9.0.0-rc.1.24406.14 to 9.0.0-rc.1.24408.12][10]
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport**: [from 9.0.0-rc.1.24379.5 to 9.0.0-rc.1.24402.2][11]
- **Microsoft.NETCore.App.Ref**: [from 9.0.0-rc.1.24406.14 to 9.0.0-rc.1.24408.12][10]
[9]: 196789faff...43360291a5
[10]: 4985021ebf...68511fd27f
[11]: bdc1e33d5d...edf3e90fa2
This pull request updates the following dependencies
## Coherency Updates
The following updates ensure that dependencies with a *CoherentParentDependency*
attribute were produced in a build used as input to the parent dependency's build.
See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview)
- **Coherency Updates**:
- **Microsoft.NET.ILLink.Tasks**: from 9.0.0-preview.7.24366.18 to 9.0.0-rc.1.24378.5 (parent: VS.Tools.Net.Core.SDK.Resolver)
- **Microsoft.AspNetCore.App.Ref**: from 9.0.0-rc.1.24375.10 to 9.0.0-rc.1.24379.7 (parent: VS.Tools.Net.Core.SDK.Resolver)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-preview.7.24366.18 to 9.0.0-rc.1.24378.5 (parent: VS.Tools.Net.Core.SDK.Resolver)
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport**: from 9.0.0-preview.7.24365.1 to 9.0.0-rc.1.24373.3 (parent: Microsoft.NETCore.App.Ref)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-preview.7.24366.18 to 9.0.0-rc.1.24378.5 (parent: VS.Tools.Net.Core.SDK.Resolver)
- **Microsoft.DotNet.Cecil**: from 0.11.5-alpha.24324.1 to 0.11.5-alpha.24365.1 (parent: Microsoft.NETCore.App.Ref)
## From https://github.com/dotnet/sdk
- **Subscription**: 3727984b-7a79-4ba3-37dd-08dbe6bddf31
- **Build**: 20240730.5
- **Date Produced**: July 30, 2024 10:19:29 PM UTC
- **Commit**: 10803eca35eef6e685924886ba74caf0bd9439ad
- **Branch**: refs/heads/main
- **Updates**:
- **VS.Tools.Net.Core.SDK.Resolver**: [from 9.0.100-rc.1.24377.4 to 9.0.100-rc.1.24380.5][16]
- **Microsoft.NET.ILLink.Tasks**: [from 9.0.0-preview.7.24366.18 to 9.0.0-rc.1.24378.5][17]
- **Microsoft.AspNetCore.App.Ref**: [from 9.0.0-rc.1.24375.10 to 9.0.0-rc.1.24379.7][18]
- **Microsoft.NETCore.App.Ref**: [from 9.0.0-preview.7.24366.18 to 9.0.0-rc.1.24378.5][17]
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport**: [from 9.0.0-preview.7.24365.1 to 9.0.0-rc.1.24373.3][19]
- **Microsoft.NETCore.App.Ref**: [from 9.0.0-preview.7.24366.18 to 9.0.0-rc.1.24378.5][17]
- **Microsoft.DotNet.Cecil**: [from 0.11.5-alpha.24324.1 to 0.11.5-alpha.24365.1][20]
[16]: 74dafbfb0c...10803eca35
[17]: 1f70f0cc66...0912e94a6c
[18]: 98ee50279a...27f2a011a4
[19]: 99ea0c06b8...40781ca2fc
[20]: 7e4af02521...e05101e694
---------
Co-authored-by: Alex Soto <alex@soto.dev>
Backport of https://github.com/xamarin/xamarin-macios/pull/20952
--------
## Description
Previous fix https://github.com/xamarin/xamarin-macios/pull/20945 did
not take into account that when we target non arm64 apple mobile
platforms we are using `MONO_AOT_MODE_INTERP_ONLY` which cannot use
dedup optimization as it discards AOT images during runtime.
## Changes
- Enable dedup only when targeting ARM64
- Fix tests to cover builds for both ARM64 and X64 builds
Finally, the change was tested against MAUI iossimulator-x64 template
app
---------
Co-authored-by: Ivan Povazan <ivan.povazan@gmail.com>
Co-authored-by: Ivan Povazan <55002338+ivanpovazan@users.noreply.github.com>
## Description
This is a follow-up PR to:
https://github.com/xamarin/xamarin-macios/pull/20936
We should not enable dedup when targeting `maccatalyst-x64` because in
case when the project file specifies
`MtouchInterpreter=all,-System.Private.CoreLib`, the build will run the
full AOT compiler with interpreter enabled.
In this setup the runtime is configured to run in interp only mode:
97a91cc4e3/tools/common/Target.cs (L812-L813)
which means that during runtime, AOT images will be ignored - aot
runtime will load them but mark them as unusuable since they are
compiled with `full` compiler switch and the code falls back to
interpreter (ref:
efebf202a4/src/mono/mono/mini/aot-runtime.c (L2131-L2148)
)
This is problematic for the `aot-instances` container image, which has a
special handling at the runtime and does not accept it to be marked as
unusable (we might want to revisit this in the future):
efebf202a4/src/mono/mono/mini/aot-runtime.c (L2527-L2529)
## Changes
This PR disables dedup optimization when targeting `maccatalyst-x64` and
updates the required tests to match the behavior.
---
Backports:
- [x] https://github.com/xamarin/xamarin-macios/pull/20946
- [x] Original reenabling of dedup for .NET 9 already includes these
changes: https://github.com/xamarin/xamarin-macios/pull/20941
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Backport of #20936
---
## 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: Ivan Povazan <ivan.povazan@gmail.com>
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
## 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>
### Description
This PR enables building app extensions with NativeAOT.
App extensions are class libraries and to build them with NativeAOT we
must not specify `CustomNativeMain=true`. If we do, ILC would expect
that the input assembly has a managed Main as the module entry point.
Additionally, when building class libraries (with the absence of a
managed Main entry point), our static reference from:
2e5ef1eb1c/runtime/nativeaot-bridge.m (L39)
requires build-time symbol resolution. To avoid linking errors, we
generate an empty `__managed__Main`
in the native bootstrapping code of the app extension (e.g., in
`main.arm64.mm`).
### Testing
The unit tests have been introduced to test building app extensions with
both Mono and NativeAOT.
Executing an iOS app TodayExtension built with NativeAOT has been
verified manually on an actual device.
---
Fixes: https://github.com/xamarin/xamarin-macios/issues/20653
This also required some changes to the generation of the workload
manifest files, since the Xcode 15.4 packages support multi-targeting.
---------
Co-authored-by: Alex Soto <alex@soto.dev>
This pull request updates the following dependencies
## Coherency Updates
The following updates ensure that dependencies with a *CoherentParentDependency*
attribute were produced in a build used as input to the parent dependency's build.
See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview)
- **Coherency Updates**:
- **Microsoft.NET.ILLink.Tasks**: from 9.0.0-preview.6.24319.11 to 9.0.0-preview.7.24357.2 (parent: VS.Tools.Net.Core.SDK.Resolver)
- **Microsoft.AspNetCore.App.Ref**: from 9.0.0-preview.6.24320.4 to 9.0.0-preview.7.24360.7 (parent: VS.Tools.Net.Core.SDK.Resolver)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-preview.6.24319.11 to 9.0.0-preview.7.24357.2 (parent: VS.Tools.Net.Core.SDK.Resolver)
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport**: from 9.0.0-preview.6.24317.2 to 9.0.0-preview.7.24319.4 (parent: Microsoft.NETCore.App.Ref)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-preview.6.24319.11 to 9.0.0-preview.7.24357.2 (parent: VS.Tools.Net.Core.SDK.Resolver)
- **Microsoft.DotNet.Cecil**: from 0.11.4-alpha.24313.1 to 0.11.5-alpha.24324.1 (parent: Microsoft.NETCore.App.Ref)
## From https://github.com/dotnet/sdk
- **Subscription**: 3727984b-7a79-4ba3-37dd-08dbe6bddf31
- **Build**: 20240711.1
- **Date Produced**: July 11, 2024 8:29:26 AM UTC
- **Commit**: 81ac886071828da7f14d0c26d731ac06abd0c7f6
- **Branch**: refs/heads/main
- **Updates**:
- **VS.Tools.Net.Core.SDK.Resolver**: [from 9.0.100-preview.7.24323.5 to 9.0.100-preview.7.24361.1][58]
- **Microsoft.NET.ILLink.Tasks**: [from 9.0.0-preview.6.24319.11 to 9.0.0-preview.7.24357.2][59]
- **Microsoft.AspNetCore.App.Ref**: [from 9.0.0-preview.6.24320.4 to 9.0.0-preview.7.24360.7][60]
- **Microsoft.NETCore.App.Ref**: [from 9.0.0-preview.6.24319.11 to 9.0.0-preview.7.24357.2][59]
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport**: [from 9.0.0-preview.6.24317.2 to 9.0.0-preview.7.24319.4][61]
- **Microsoft.NETCore.App.Ref**: [from 9.0.0-preview.6.24319.11 to 9.0.0-preview.7.24357.2][59]
- **Microsoft.DotNet.Cecil**: [from 0.11.4-alpha.24313.1 to 0.11.5-alpha.24324.1][62]
[58]: ea9243f9cb...81ac886071
[59]: 117cfccdd7...4e278fe17f
[60]: 613c1e990b...71b5ef3f5c
[61]: 9880d891dd...ffe9afdc04
[62]: d145726036...7e4af02521
* Remove code to test NWPath.EnumerateInterfaces, because this method is already tested elsewhere.
* Assume that if the test fails to find any gateways, it might be because the
current machine doesn't have any (which happens on one of my machines), and
in that case ignore the test.
Move the architecture-specific vargs implementation of UIAppearance.GetAppareance into a more generic way of calling objc_msgSend with variadic arguments.
This prepares the way for more APIs with variadic arguments (which is coming in Xcode 16).
When building universal apps, each inner build must add the runtime identifier to the output path, otherwise the inner builds may conflict with eachother, overwriting eachother's files.
That's bad.
So we explicitly set `AppendRuntimeIdentifierToOutputPath` to `true` when building inner builds.
* xtro: Fix how we build the u2todo project to actually build the correct project.
* Don't import eng/Versions.props in several test projects, it's already imported in a Directory.Build.props further up the directory hierarchy.
We don't really care about the value, and keeping track of whether the
calendar is immutable or not to assert the right value is time-consuming, so
just don't do that.
Apple has flip-flopped between the two possible exception messages depending
on platform and OS version, and it's difficult and annoying to keep track.
So just don't: always accept either exception message. It doesn't really matter which one we get.s
Convert all projects except xtro-sharpie.csproj to .NET projects.
xtro-sharpie.csproj can't be converted yet, because it depends on
Objective-Sharpie, which hasn't been converted yet.
Apple says the bug on their side causing a runtime crash has been fixed since
macOS 12, so unignore the code and add a version check for macOS 12.
Fixes https://github.com/xamarin/maccore/issues/2345.
When finding an enumerator for the given code:
```cs
var collection = new NSSet<NSNumber> ();
foreach (var item in collection) {
// ...
}
```
the C# compiler will first look for any `GetEnumerator` methods. The non-generic `NSSet` class defines a `IEnumerator<NSObject> GetEnumerator<NSObject> ()` method, which, since the generic `NSSet<T>` class doesn't define such a method, is selected.
The end result is that the type of the foreach element is `NSObject`
(`GetEnumerator`'s return type') - which is somewhat unexpected:
```cs
var collection = new NSSet<NSNumber> ();
foreach (var item in collection) {
Console.WriteLine (item.LongValue); // error CS1061: 'NSObject' does not contain a definition for 'LongValue'
}
```
The fix is to define a `IEnumerator<T> GetEnumerator<T> ()` method in the
generic `NSSet<T>` class, which the C# will find and choose over the base
class' method. Then the type of the foreach element is the correct type, and
the following code works:
```cs
var collection = new NSSet<NSNumber> ();
foreach (var item in collection) {
Console.WriteLine (item.LongValue); // it works!
}
```
Do this for all our generic collection classes.
Also document these methods + all the other public `GetEnumerator` methods.
We noticed we weren't seeing trim analysis warnings in VS Code when
PublishAot was set to true. There was a recent change that correctly
disabled the suppressions when TrimMode is full. We need to make sure
that we're also getting the trim analysis warnings in dotnet build with
PublishAot but suppress them when publishing (in that case the warnings
will come later from ILC). This PR aligns the behavior of
PublishAot=true and TrimMode=true in debug builds.
There's no need to support `RuntimeIdentifiers` (plural) for Hot Restart
(because we don't have any scenarios where multiple runtime identifiers
applies to iOS; a single runtime identifier can always be used).
Adding support would make our code base more complex, so just avoid it by
showing an early error if someone tries (which is likely to be accidental
anyways).
This way we show an actionable error message for a scenario customers will
probably be confused about (because the build would fail in rather
inexplicable ways) if they run into it.
Partial fix for https://github.com/xamarin/xamarin-macios/issues/19262.
Fix BuildBindingsTest expectations to expect the resources in either a sidecar or a zipped sidecar.
Fixes this test failure:
Xamarin.Tests.DotNetProjectTest.BuildBindingsTest(TVOS): Bundle existence
Expected: file or directory exists
But was: "/Users/builder/azdo/_work/1/s/xamarin-macios/tests/bindings-test/dotnet/tvOS/bin/Debug/net8.0-tvos/bindings-test.resources.zip"
We need the backwards compatible code for the
AVSampleCursorAudioDependencyInfo struct (i.e. use the
AVSampleCursorAudioDependencyInfo_Blittable version), so adjust the ifdefs
accordingly - which wasn't obvious at first, because __IOS__ is defined for
Mac Catalyst.
Also fix the corresponding test, because it would cache the result of
computing whether a struct was blittable or not, but that's not true across
platforms ("AVSampleCursorAudioDependencyInfo" is blittable on iOS, but not on
Mac Catalyst). The result was that the test would incorrectly pass if we
processed Microsoft.iOS.dll before Microsoft.MacCatalyst.dll. The fix is to
cache per platform, instead of using a global cache.
This pull request updates the following dependencies
## Coherency Updates
The following updates ensure that dependencies with a *CoherentParentDependency*
attribute were produced in a build used as input to the parent dependency's build.
See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview)
- **Coherency Updates**:
- **Microsoft.NET.ILLink.Tasks**: from 9.0.0-preview.5.24256.1 to 9.0.0-preview.6.24281.1 (parent: VS.Tools.Net.Core.SDK.Resolver)
- **Microsoft.AspNetCore.App.Ref**: from 9.0.0-preview.5.24256.2 to 9.0.0-preview.6.24305.3 (parent: VS.Tools.Net.Core.SDK.Resolver)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-preview.5.24256.1 to 9.0.0-preview.6.24281.1 (parent: VS.Tools.Net.Core.SDK.Resolver)
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport**: from 9.0.0-preview.5.24223.2 to 9.0.0-preview.6.24277.2 (parent: Microsoft.NETCore.App.Ref)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-preview.5.24256.1 to 9.0.0-preview.6.24281.1 (parent: VS.Tools.Net.Core.SDK.Resolver)
## From https://github.com/dotnet/sdk
- **Subscription**: 3727984b-7a79-4ba3-37dd-08dbe6bddf31
- **Build**: 20240605.17
- **Date Produced**: June 5, 2024 11:40:08 PM UTC
- **Commit**: 6ecc573c92a1237627b37310c6aec65ff3caacc8
- **Branch**: refs/heads/main
- **Updates**:
- **VS.Tools.Net.Core.SDK.Resolver**: [from 9.0.100-preview.5.24262.2 to 9.0.100-preview.6.24305.17][65]
- **Microsoft.NET.ILLink.Tasks**: [from 9.0.0-preview.5.24256.1 to 9.0.0-preview.6.24281.1][66]
- **Microsoft.AspNetCore.App.Ref**: [from 9.0.0-preview.5.24256.2 to 9.0.0-preview.6.24305.3][67]
- **Microsoft.NETCore.App.Ref**: [from 9.0.0-preview.5.24256.1 to 9.0.0-preview.6.24281.1][66]
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport**: [from 9.0.0-preview.5.24223.2 to 9.0.0-preview.6.24277.2][68]
- **Microsoft.NETCore.App.Ref**: [from 9.0.0-preview.5.24256.1 to 9.0.0-preview.6.24281.1][66]
[65]: 1741345c63...6ecc573c92
[66]: 84b3339505...3750ac5161
[67]: da3aa27233...8adff2c3cf
[68]: 53288f87c5...fae2c95346
---------
Co-authored-by: Alex Soto <alex@alexsoto.me>
Change how we compute DTPlatformName so that it's 'macosx' for Mac Catalyst.
The PlatformUtils.GetTargetPlatform returns SdkPlatform for all platforms
except Mac Catalyst, where it returns the same as for macOS (i.e. 'macosx').
It also returns a lowercased value, so we don't need to do that either.
This is a partial fix for https://github.com/xamarin/xamarin-macios/issues/20714.
Rolf Bjarne Kvinge
dotnet-maestro[bot]
Peter Collins
Manuel de la Pena
Alex Soto
Ivan Povazan
Alex Soto
Šimon Rozsíval