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.
In these cases the APIs in question aren't used in P/Invokes at the moment,
but that may change, so just make as much as we can blittable by removing any
MarshalAs attributes.
Make a few GameController structs blittable, which requires some workarounds
to the fact that these changes would be breaking changes - we're keeping the
old structs, and instead introduce internal blittable versions which are then
used in the api definitions (and thus generated P/Invokes).
Given the following API definition:
```cs
[Protocol]
public interface Protocol {
[Abstract]
[Export ("requiredMethod")]
void RequiredMethod ();
[Export ("optionalMethod")]
void OptionalMethod ();
}
```
we're now binding it like this:
```cs
[Protocol ("Protocol")]
public interface IProtocol : INativeObject {
[RequiredMember]
[Export ("requiredMethod")]
public void RequiredMethod () { /* default implementation */ }
[OptionalMember]
[Export ("optionalMethod")]
public void OptionalMethod () { /* default implementation */ }
}
```
The main difference from before is that the only difference between required
and optional members is the [RequiredMember]/[OptionalMember] attributes.
This has one major advantage: it's now possible to switch a member from being
required to being optional, or vice versa, without breaking neither source nor
binary compatibility.
It also improves intellisense for optional members. In the past optional
members were implemented using extension methods, which were not very
discoverable when you were supposed to implement a protocol in your own class.
The main downside is that the C# compiler won't enforce developers to
implement required protocol members (which is a necessary side effect of the
fact that we want to be able to switch members between being required and
optional without breaking compatibility). If this turns out to be a problem,
we can implement a custom source analyzer and/or linker step that detects
missing implementations and issue warnings/errors.
This PR also:
* Adds numerous tests.
* Updates the requiredness of a few members in Metal to test that it works as
expected.
* Adds documentation.
* Handles numerous corner cases, which are documented in code and docs.
This PR is probably best reviewed commit-by-commit.
Fixes https://github.com/xamarin/xamarin-macios/issues/13294.
## Description
This PR enables the dedup optimization in FullAOT mode only. The
optimization can only run in FullAOT mode with complete application
context. Without it, the AOT compiler may fail to collect all generic
instances, and the runtime can't find them as they are searched in the
dedup assembly.
## Changes
This PR updates the SDK targets to enable dedup optimization in FullAOT
mode only. This change doesn't depend on any runtime changes.
## Verification
This PR also introduces partial AOT tests. They inspect the bundle for
`aot-instances.dll`, which shouldn't be generated in a partial AOT
compilation setup. Additionally, basic functionality is tested by
asserting at app startup.
## Additional notes
This change should be backported to .NET 8 as well.
Fixes https://github.com/dotnet/runtime/issues/99248
* The AVSampleCursor type was made available on all platforms two years ago (as
opposed to only macOS before that), so update availability attributes accordingly.
* Also make a few structs used by AVSampleCursor blittable (AVSampleCursorSyncInfo,
AVSampleCursorDependencyInfo, AVSampleCursorChunkInfo, AVSampleCursorAudioDependencyInfo)
This got a bit complicated, because some of the non-blittable members of these structs
are public. This meant a workaround had to be implemented:
* Rename the properties that use these structures - appending "_Blittable" - and
make them internal.
* Create internal "*_Blittable" versions of the structures, and a make the "_Blittable"
properties return these structures.
* Bind the properties again, wrapping the internal versions and manually converting
from the blittable structures to the non-blittable structures.
Note that since some of the properties are new on iOS and tvOS, we don't need the
compatibility workaround for these platforms.
Contributes towards #15684.
Import all the xml documentation for types from https://github.com/xamarin/apple-api-docs.
Some of this documentation should probably be rewritten, and potentially moved
to conceptual documentation, in particular those that contain images (because
images can't be imported into xml documentation).
Note that the documentation hasn't been modified in any way; that's not the purpose of this PR. If documentation should be modified for whatever reason, it can be done in a later PR.
The xml documentation for members will come in a later PR.
Partial fix for https://github.com/xamarin/xamarin-macios/issues/17399.
This is mostly to ensure that in XAMCORE_5_0 we fix all APIs with MarshalAs
attributes, because in order to not break binary compatibility, we can't fix
all of these failures right now.
Additionally it ensures we don't add more APIs with MarshalAs attributes.
Fix BundleStructure when building for only tvOS by detecting whether the
bindings are zipped or not by detecting the presence of the zip file, instead
of computing it based on the current platform (which becomes problematic,
because whether or not a binding project produces a zip file may depend on
whether other platforms are enabled or not).
This test doesn't work when building on iossimulator-arm64 or
tvossimulator-arm64, because we're trying to use a fat framework which doesn't
have that architecture (it contains the device arm64 architecture instead).
So just disable this test on iOS and tvOS - the solution is using an
xcframework, and we already have a different test for that.
---------
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Call mono_unhandled_exception to raise AppDomain.UnhandledException when
managed exceptions are unhandled.
Partial fix for #15252 (for MonoVM, still pending for CoreCLR, which
needs https://github.com/dotnet/runtime/issues/102730 fixed first).
The logic to update the request's RequestUri is somewhat old:
518ac1bf19
but it makes sense to do so.
Some testing with a console app, also revealed that a plain .NET does this in
case of a redirect:
```cs
async static Task Main ()
{
var client = new HttpClient () { BaseAddress = new Uri("https://httpbin.org") };
var request = new HttpRequestMessage (HttpMethod.Get,
"/redirect-to?url=https%3A%2F%2Fmicrosoft.com&status_code=302&queries[]={}"
);
Console.WriteLine ($"Request uri 1: {request.RequestUri}");
var response = await client.SendAsync(request);
Console.WriteLine ($"Request uri 2: {request.RequestUri}");
var content = await response.Content.ReadAsStringAsync();
Console.WriteLine ((int) response.StatusCode);
Console.WriteLine(content.Length);
}
```
prints:
```
Request uri 1: /redirect-to?url=https%3A%2F%2Fmicrosoft.com&status_code=302&queries[]={}
Request uri 2: https://www.microsoft.com/es-es/
200
201252
```
Further looking into .NET's code, `SocketsHttpHandler` updates RequestUri after
following a redirect:
f5eb26e4da/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/RedirectHandler.cs (L65-L66)
So it seems the expected behavior is to update RequestUri only in case of a
redirect.
Now the question becomes: how to detect whether we're a redirect or not?
Contrary to `SocketsHttpHandler`, we don't do the actual redirect, it's
handled transparently by `NSUrlSession`.
Fortunately `NSUrlSessionTask` has two properties which help:
[`OriginalRequest`][1] and [`CurrentRequest`][2]. According to Apple's
documentation, these are the same, "except when the server has responded to
the initial request with a redirect to a different URL."
This sounds perfect for us, so use these two properties to determine whether a redirect occurred.
Note that we can't use object identity, because these are 'copy' properties,
which means they'll never be the same instances, only at most a copy of
eachother. So instead compare the `AbsoluteString` property to check for
equality. As far as I'm aware, none of the other properties (request body,
headers, cookies, etc.) can be set by the server in a redirect, so there's no
need to compare those.
Fixes https://github.com/xamarin/xamarin-macios/issues/20629.
[1]: https://developer.apple.com/documentation/foundation/nsurlsessiontask/1411572-originalrequest
[2]: https://developer.apple.com/documentation/foundation/nsurlsessiontask/1411649-currentrequest
GCMouse doesn't conform to NSCoding/NSSecureCoding, so fix the API definition.
Since this would be a breaking change, also add compat code to preserve binary
compatibility.
Fixes this test:
Introspection.MacApiSelectorTest
[FAIL] InstanceMethods : 1 errors found in 33428 instance selector validated:
Selector not found for GameController.GCMouse : encodeWithCoder: in Void EncodeTo(Foundation.NSCoder) on GameController.GCMouse
Expected: 0
But was: 1
[FAIL] Selector not found for GameController.GCMouse : encodeWithCoder: in Void EncodeTo(Foundation.NSCoder) on GameController.GCMouse
at Introspection.ApiSelectorTest.InstanceMethods() in /Users/rolf/work/maccore/net9.0/xamarin-macios/tests/introspection/ApiSelectorTest.cs:line 1121
Add support for binding constructors in protocols.
Given the api definition:
```cs
[Protocol]
public interface Protocol {
[Abstract]
[Export ("init")]
IntPtr Constructor ();
[Export ("initWithValue:")]
IntPtr Constructor (IntPtr value);
[BindAs ("Create")]
[Export ("initWithPlanet:")]
IntPtr Constructor ();
}
```
we're binding it like this:
```cs
[Protocol ("Protocol")]
public interface IProtocol : INativeObject {
[Export ("init")]
public static T CreateInstance<T> () where T: NSObject, IProtocol { /* default implementation */ }
[Export ("initWithValue:")]
public static T CreateInstance<T> () where T: NSObject, IProtocol { /* default implementation */ }
[Export ("initWithPlanet:")]
public static T Create<T> () where T: NSObject, IProtocol { /* default implementation */ }
}
```
Also add documentation and tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/14039.
---------
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Alex Soto <alex@soto.dev>
So instead of this:
> Cecil.Tests.Documentation+AssemblyApi: Documented API not found in the platform assembly. This probably indicates that the code to compute the doc name for a given member is incorrect.
we'll get:
> T:Foundation.SomeType: Documented API not found in the platform assembly. This probably indicates that the code to compute the doc name for a given member is incorrect.
iOS (and presumably tvOS) app bundles can't contain a subdirectory named "Resources".
Apple says:
> Note: An iOS app bundle cannot include a custom folder named “Resources.”
Ref: https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW1
Unfortunately Apple's toolchain won't show a helpful error message, the
eventual failure is codesign saying something like this:
bin/Release/net8.0-ios/ios-arm64/SomeApp.app: code object is not signed at all
In subcomponent: bin/Release/net8.0-ios/ios-arm64/SomeApp.app/System.Security.Cryptography.aotdata.arm64
Which is confusing, to say the least.
After debugging this myself a few times, and seeing customers running into the
same issue periodically, it's time to make the error more actionable.
I've added code to our Codesign task to detect the "Resources" subdirectory,
and show a better error message. There's also a way to disable the validation
(by setting `CodesignDisallowResourcesSubdirectoryInAppBundle=false`), just in
case we end up being overeager with the validation.
Fixes https://github.com/xamarin/xamarin-macios/issues/20135.
---------
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
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.
A `*.framework/` native reference and a `*.framework` reference are the same
thing, so treat them the same. We accomplish this by removing any trailing
path separators (both windows style and non-windows-style for consistency)
before doing any processing.
Fixes https://github.com/xamarin/xamarin-macios/issues/15430.
We've recently started using more and more ARM64 bots, so these tests are
failing in those cases.
Fixes:
MonoTouchFixtures.Security.SecureTransportTest
[FAIL] SslSupportedCiphers : 3224092716
Expected: True
But was: False
at MonoTouchFixtures.Security.SecureTransportTest.SslSupportedCiphers () [0x000de] in <f08bd76ea2204d929c96e3bd36ae955a>:0
Xamarin.Mac.Tests.EveryFrameworkSmokeTests
[FAIL] ExpectedLibrariesAreLoaded : QTKitLibrary (/System/Library/Frameworks/QTKit.framework/QTKit) failed to load but this was not expected
at Xamarin.Mac.Tests.EveryFrameworkSmokeTests.ExpectedLibrariesAreLoaded () [0x000e6] in <f08bd76ea2204d929c96e3bd36ae955a>:0
The enum value MethodAttributes.IsFamily is 'internal' in C#, which is not exposed
outside an assembly, so don't count such members as exposed. On the other hand, MethodAttributes.IsAssembly
is 'protected' in C#, which *is* exposed, so these members are included.
Update tests accordingly.
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.
This was complicated a bit because it uses a non-blittable struct we can't
change because it's public API. So introduce an internal temporary blittable
struct.
Contributes towards #15684.
The generator needs a library name for the generated `_domain` field.
Here's an example for the generated `ARErrorCodeExtensions` class ("ARKit" is
the library name):
```cs
[Field ("ARErrorDomain", "ARKit")]
static NSString? _domain;
```
In order to find the library name, the generator would look at the first enum
field with a `[Field]` attribute, and get the `LibraryName` property from that
`[Field]` attribute. Unfortunately error enums don't necessarily have `[Field]`
attributes on their enum fields. This works fine for our own bindings, because
the generator will fall back to the enum's namespace, but for third-party
bindings this would be the result:
> error BI1042: bgen: Missing '[Field (LibraryName=value)]' for ErrorDomainNS.EWithDomain. (e.g."__Internal")
Note that the error message is rather confusing: it's trying to report a
missing `LibraryName` property for a `[Field]` attribute, but there's no `[Field]`
attribute anywhere in the enum in question.
So fix this by:
* Adding the `LibraryName` property on the `[ErrorDomain]` attribute.
* Implement support for looking at this new property in the generator.
* Report a better error if it's not there.
The GKHybridStrategist type doesn't exist in iOS. This was probably a type
initially introduced in a beta version, and then removed in a later beta
version, and then we didn't notice.
Stop using the term 'Xamarin' in our error messages.
🙈🙊🙉
Note: this may not be complete, since we compute error messages in numerous
places, and those aren't fixed here (if there are any that still says
'Xamarin' in any way).
---------
Co-authored-by: Michael Cummings (MSFT) <mcumming@microsoft.com>
NUnit is not trimmer-safe, and produces a lot of trimmer warnings.
Ideally we'll fix NUnit or come up with an alternative (see #19911), but
that's a significant amount of work.
We also want to turn warnings into errors (to avoid adding more trimmer
warnings by accident).
So we disable trimmer warnings from NUnit. The method is somewhat complex,
because there's no built-in way to ignore warnings for a given assembly, but
both ILC and ILLink provides a way to collapse multiple warnings into a single
warning (with a specific code) on a per assembly basis, and we can levarage
this:
* We enable all warnings for all assemblies (by setting
`TrimmerSingleWarn=false`).
* We enable the single-warning mode for NUnit only.
* We ask the trimmer to not warn about the specific warning code given for the
single-warning produced.
The end result is that we won't get any trimmer warnings for NUnit.
An xharness fix was also needed to make xharness not get confused with
ItemGroups inside Targets when cloning project files.
Ref: https://github.com/xamarin/xamarin-macios/issues/19911
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.3.24129.2 to 9.0.0-preview.4.24209.8 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 9.0.0-preview.3.24151.1 to 9.0.0-preview.4.24208.6 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-preview.3.24129.2 to 9.0.0-preview.4.24209.8 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport**: from 9.0.0-preview.3.24126.1 to 9.0.0-preview.4.24204.9 (parent: Microsoft.NETCore.App.Ref)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-preview.3.24129.2 to 9.0.0-preview.4.24209.8 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.DotNet.Cecil**: from 0.11.4-alpha.24120.1 to 0.11.4-alpha.24168.1 (parent: Microsoft.NETCore.App.Ref)
## From https://github.com/dotnet/installer
- **Subscription**: 3727984b-7a79-4ba3-37dd-08dbe6bddf31
- **Build**: 20240411.4
- **Date Produced**: April 11, 2024 3:25:11 PM UTC
- **Commit**: c61f05c5628fdba80433184eb00353a908dbdccc
- **Branch**: refs/heads/main
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 9.0.100-preview.3.24153.2 to 9.0.100-preview.4.24211.4][106]
- **Microsoft.NET.ILLink.Tasks**: [from 9.0.0-preview.3.24129.2 to 9.0.0-preview.4.24209.8][107]
- **Microsoft.AspNetCore.App.Ref**: [from 9.0.0-preview.3.24151.1 to 9.0.0-preview.4.24208.6][108]
- **Microsoft.NETCore.App.Ref**: [from 9.0.0-preview.3.24129.2 to 9.0.0-preview.4.24209.8][107]
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport**: [from 9.0.0-preview.3.24126.1 to 9.0.0-preview.4.24204.9][109]
- **Microsoft.NETCore.App.Ref**: [from 9.0.0-preview.3.24129.2 to 9.0.0-preview.4.24209.8][107]
- **Microsoft.DotNet.Cecil**: [from 0.11.4-alpha.24120.1 to 0.11.4-alpha.24168.1][110]
[106]: 893b762b6e...c61f05c562
[107]: 5e603d595e...6b9381be09
[108]: 3e5155276f...79ef5e329b
[109]: 0f3e462442...9ad7c262f1
[110]: 0d0bc8e0f4...9c8ea966df
---------
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Alex Soto <alex@soto.dev>
The UITextAttributes.Dictionary property is supposed to work like the
UIStringAttributes.Dictionary property, but there's one big difference: the
UITextAttributes version can (and calling code does) be disposed, while the
UIStringAttributes version can't.
This is because the UITextAttributes version creates a new dictionary every
time, while the UIStringAttributes version doesn't.
Since properties shouldn't really do much, it makes sense to remove the
UITextAttributes version, and instead rely on the
UITextAttributes.ToDictionary method, where the difference in behavior is more
obvious.
This required a few changes in calling code, which used either UITextAttributes
or UIStringAttributes using conditional compilation.
Fixes https://github.com/xamarin/xamarin-macios/issues/20409.
Fixes this test failure:
MonoTests.System.Net.Http.MessageHandlerTest.GHIssue16339
[FAIL] GHIssue16339() : ReasonPhrase #1
Expected string length 2 but was 11. Strings differ at index 0.
Expected: "OK"
But was: "Bad Gateway"
Also expose both getter and setter methods using the enum itself, so we don't
have to make getter and setter properties for each of the enum fields.
This required making CGEventField a public enum, so do that.
And finally document all the new APIs, and some of the old ones.
Fixes https://github.com/xamarin/xamarin-macios/issues/12650.
Rolf Bjarne Kvinge
Peter Collins
dotnet-maestro[bot]
Manuel de la Pena
Alex Soto
Ivan Povazan
Alex Soto
Šimon Rozsíval
Milos Kotlar
Haritha Mohan