Add partial support for the `[Preserve]` attribute for NativeAOT. This
is done by injecting an equivalent `[DynamicDependency]` attribute. The
partial support comes from the fact that there's no way to map a
conditional preserve attribute (`[Preserve (Conditional = true)]`) to a
`[DynamicDependency]` attribute, so we report a warning instead.
For non-conditional `[Preserve]` attributes, we'll now add a
`[DynamicDependency]` attribute to the assembly's module constructor for
the type/member in question, effectively rooting it.
This makes it possible to fully link all our test suites when NativeAOT
(otherwise NativeAOT would just link out all the tests, leaving the test
suites empty - and unfortunately green, so this was a rather accidental
discovery).
It's possible to create a provisioning profile for Mac Catalyst that
doesn't allow dylibs in the app. It seems a significant number of people run
into this problem when publishing their apps, so avoid it by linking Mono and
Xamarin statically by default instead.
The downside is that build time might increase a little bit.
An upside however is that the app size might decrease somewhat.
Fixes https://github.com/xamarin/xamarin-macios/issues/14686.
Change all null checking expressions to use 'is null' and 'is not null'
instead of '== null' and '!= null'.
This was mostly done with sed, so code can probably be improved in many
other ways with manual inspection, but that will come over time.
Also add code to the autoformat script to automatically fix these issues in the future.
We mark all types that derive from NSObject when we find them in user
assemblies, so that these types may be used in storyboards (where the linker
can't see them), without having to go through hoops to make sure the linker
doesn't remove these types (which would make the storyboard fail to load,
because it would reference types that were linked away).
However, not everybody uses storyboards, so in some cases it may make sense to
link away as much as possible, so make it opt-in to skip this custom marking.
This is an experimental feature, and will break at least some apps. It may
break most apps, but if someone wants to try it out, they're welcome!
It can be turned on by passing `--skip-marking-nsobjects-in-user-assemblies=true` to mtouch/mmp:
```xml
<PropertyGroup>
<MtouchExtraArgs>--skip-marking-nsobjects-in-user-assemblies=true</MtouchExtraArgs>
</PropertyGroup>
```
Fixes#15723.
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 8.0.0-preview.3.23171.4 to 8.0.0-preview.4.23176.4 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 8.0.0-preview.4.23171.7 to 8.0.0-preview.4.23176.6 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-preview.3.23171.4 to 8.0.0-preview.4.23176.4 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100.Transport**: from 8.0.0-preview.3.23167.1 to 8.0.0-preview.4.23170.1 (parent: Microsoft.NETCore.App.Ref)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-preview.3.23171.4 to 8.0.0-preview.4.23176.4 (parent: Microsoft.Dotnet.Sdk.Internal)
## From https://github.com/dotnet/installer
- **Subscription**: 9a2944cb-7dee-4bf2-a65c-08dabd10ae64
- **Build**: 20230328.2
- **Date Produced**: March 28, 2023 10:27:20 AM UTC
- **Commit**: 69e28735b98581f2ee0825953de83a8581df7563
- **Branch**: refs/heads/main
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 8.0.100-preview.4.23172.3 to 8.0.100-preview.4.23178.2][21]
- **Microsoft.NET.ILLink.Tasks**: [from 8.0.0-preview.3.23171.4 to 8.0.0-preview.4.23176.4][22]
- **Microsoft.AspNetCore.App.Ref**: [from 8.0.0-preview.4.23171.7 to 8.0.0-preview.4.23176.6][23]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-preview.3.23171.4 to 8.0.0-preview.4.23176.4][22]
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100.Transport**: [from 8.0.0-preview.3.23167.1 to 8.0.0-preview.4.23170.1][24]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-preview.3.23171.4 to 8.0.0-preview.4.23176.4][22]
[21]: 27622e3898...69e28735b9
[22]: edb161ab06...8d5f520838
[23]: 16907a1efa...c2350729d0
[24]: 25d9f7a5e3...a464820353
There's a 'link all' test that's verifying that the IntroducedAttribute is
linked away. It does so by verifying that the linked app doesn't have a
'IntroducedAttribute' type - but the test was constructing the fully qualified
type name to look for incorrectly:
ObjCRuntime.IntroducedAttribute, , Microsoft.iOS
Note the double comma: that meant we wouldn't find the type, even if it wasn't linked away.
The fix is easy (use a single comma), with one caveat (don't use a constant
string, because the linker sees the reference to
"ObjCRuntime.IntroducedAttribute" and _helpfully_ preserves it, exactly what
we don't want), but it revealed that the tested behavior regressed: a fully
linked app wouldn't link away the IntroducedAttribute.
So a fix is also needed: properly remove TVAttribute, WatchAttribute and
MacCatalystAttribute, which are subclasses of IntroducedAttribute (and what
would make the linker keep IntroducedAttribute).
Interestingly this showed up because of a bug in the runtime, where parsing
the invalid assembly name would now throw an exception
(https://github.com/dotnet/runtime/issues/84118).
This pull request updates the following dependencies
## From https://github.com/dotnet/installer
- **Subscription**: 9a2944cb-7dee-4bf2-a65c-08dabd10ae64
- **Build**: 20230306.1
- **Date Produced**: March 6, 2023 10:15:46 AM UTC
- **Commit**: 51e06f6931e859f56564556fa6ba519761fa7141
- **Branch**: refs/heads/main
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 8.0.100-preview.2.23108.2 to 8.0.100-preview.3.23156.1][77]
- **Microsoft.NET.ILLink.Tasks**: [from 8.0.0-preview.2.23107.1 to 8.0.0-preview.2.23127.4][78]
- **Microsoft.AspNetCore.App.Ref**: [from 8.0.0-preview.2.23107.2 to 8.0.0-preview.3.23127.13][79]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-preview.2.23107.1 to 8.0.0-preview.2.23127.4][78]
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100-preview.2**: [from 8.0.0-preview.2.23081.3 to 8.0.0-preview.2.23113.1][80]
[77]: 5a84050...51e06f6
[78]: e71a4fb...2bdc3cb
[79]: cec7fbf...3265dc6
[80]: 1d9df33...d7ff0aa
## 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.0-preview.2.23107.1 to 8.0.0-preview.2.23127.4 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 8.0.0-preview.2.23107.2 to 8.0.0-preview.3.23127.13 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-preview.2.23107.1 to 8.0.0-preview.2.23127.4 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100-preview.2**: from 8.0.0-preview.2.23081.3 to 8.0.0-preview.2.23113.1 (parent: Microsoft.NETCore.App.Ref)
Add support for function pointers to BlockLiteral, and use it to update
almost all manually bound block code to use function pointers (in .NET).
Also add support to the linker for optimizing the new block API.
Contributes towards https://github.com/xamarin/xamarin-macios/issues/15783.
This PR has the AVKit updates and introduces the AVRouting bindings that
are interconnected with AVKit
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
Otherwise the P/Invoke generator leaves partial results in the static
registrar class, essentially saying things like "we've processed CoreMidi, no
need to add an #include for this framework", and then we'd generate the static
registrar code and that code would lack the #include for CoreMidi.
Finishing the P/Invoke generator output will clear out any state stored in the
static registrar.
Also fix a few other issues to make the generated P/Invoke wrapper code work,
and add a test.
Fixes https://github.com/xamarin/xamarin-macios/issues/15190.
* This is a potential mitigation for slower transition to native code when
exception marshalling is enabled (#14812).
* A minor modification was required in the linker, to make sure any modified
assemblies are saved.
Fixes https://github.com/xamarin/xamarin-macios/issues/4940.
I'm very pleased to present full bindings to the MetalPerformanceShadersGraph framework!
I'm happy with how everything turned out with the exception of a few notes and questions below.
I re-implemented Apple's MNIST sample (from https://developer.apple.com/documentation/metalperformanceshadersgraph/training_a_neural_network_using_mps_graph) here:
https://gist.github.com/praeclarum/b8077771fb341a1f9c28240113e00425
It's also added as a unit test.
Fixes#14286
### Notes
* Although the API says it works on macOS 11, it has bugs and crashes with errors even with Apple’s Swift examples. It’s better on macOS 12. iOS 14 and on is fine.
* `MPSGraphSparseStorageType` has terrible names. They match Apple's but I wish they were better.
* I added convenience methods to `MPSNDArray` and `MPSGrapTensorData` and the `Variable` and `Constant` operations to decrease the amount of unsafe code users have to write. I currently do this for 32-bit floats, the most common data type.
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
CHIP framework seems to not be stable yet from Apple's side
each xcode update it brings breaking changes and it is also
not documented anywhere so let's disable it for now and
we can re-enable it in the future once it is stable.
Thinks are working fine as-is (with this XAMCORE_4_0 variable set to false),
and I see no particular reason in the code to change it, nor does the original
implementation explain much (b2bcad7a94).
So just remove this XAMCORE_4_0 condition as if it had never existed.
The QTKit framework does not exist on macOS anymore, so just remove our
bindings for it now that we can break compatibility.
Fixes a lot of errors like this when building with XAMCORE_4_0:
> build/dotnet/macos/generated-sources/Accessibility/AXCategoricalDataAxisDescriptor.g.cs(14,7): error CS0246: The type or namespace name 'QTKit' could not be found (are you missing a using directive or an assembly reference?)
> build/dotnet/macos/generated-sources/Accessibility/AXChart.g.cs(14,7): error CS0246: The type or namespace name 'QTKit' could not be found (are you missing a using directive or an assembly reference?)
> build/dotnet/macos/generated-sources/Accessibility/AXChartDescriptor.g.cs(14,7): error CS0246: The type or namespace name 'QTKit' could not be found (are you missing a using directive or an assembly reference?)
> build/dotnet/macos/generated-sources/Accessibility/AXChartDescriptorContentDirection.g.cs(14,7): error CS0246: The type or namespace name 'QTKit' could not be found (are you missing a using directive or an assembly reference?)
> build/dotnet/macos/generated-sources/Accessibility/AXCustomContent.g.cs(14,7): error CS0246: The type or namespace name 'QTKit' could not be found (are you missing a using directive or an assembly reference?)
> build/dotnet/macos/generated-sources/Accessibility/AXCustomContentImportance.g.cs(14,7): error CS0246: The type or namespace name 'QTKit' could not be found (are you missing a using directive or an assembly reference?)
> [...]
The "product assembly" is supposed to be Xamarin.iOS.dll, Xamarin.Mac.dll,
etc., not other assemblies, so fix the implementation to reflect this. The
original commit where MonoTouch.Dialog-1 and MonoTouch.NUnitLite were
introduced as platform assemblies is quite old [1], and doesn't explain much,
but I believe the intention was to make us treat these assemblies as *SDK*
assemblies and link them accordingly, so I made these assemblies SDK assemblies now.
Additionally remove "Xamarin.iOS" as a hardcoded platform assembly for Mac
Catalyst, because this particular code is exclusive to legacy Xamarin, and Mac
Catalyst support will only be included in our .NET release, which means this
code does not have any purpose here, and might even break something one day.
[1]: 0349f8d47f
Fixes https://github.com/xamarin/xamarin-macios/issues/12862.
When checking if we need to manually preserve a native symbol, we need to
check if a P/Invoke matches both static and dynamic libraries from the Mono
runtime, not just dynamic libraries.
This also required changing some linker code to not have platform-specific conditional compilation,
because dotnet-linker is built only once for .NET (same binary for all platforms).
when (by default)
* the interpreter is not enabled (since new code might subclass or override the members analyzed at build time)
* building for release
Reverts c56b893b68
Fix https://github.com/xamarin/xamarin-macios/issues/9573
Notes
* Even if possible (in metadata) there is no point in setting `final` on
a method if we remove `virtual`. This match ILLink version of the sealer
and makes the same test pass on both.
* Don't apply optimization on non-AOT builds, e.g. simulators, since some
features (like XML serialization) checks for
`RuntimeFeature.IsDynamicCodeSupported` and that requires some types
to be subclassed thru SRE
Previously we'd only call Runtime.RegisterEntryAssembly in the simulator if
the dynamic registrar was available, but now we may call it on device as well
(still only if the dynamic registrar is available). So modify the linker to
keep Runtime.RegisterEntryAssembly even if we're executing on device, as long
as the dynamic registrar is around.
This ensures we get the same behavior both in the simulator and on device (and
desktop for that matter).
Fixes https://github.com/xamarin/xamarin-macios/issues/12327.