Also introduce a few other improvements:
* Add an varation that takes an 'out bool' instead of a 'ref bool'. According
to the documentation the value is out-only.
* Name this variation according to our guidelines (with a verb).
* Deprecate the old version.
Contributes towards https://github.com/xamarin/xamarin-macios/issues/15684.
This is a step (among many) towards merging the iOS and Mac task assemblies
into a single assembly, which would simplify and speed up our build quite a bit.
This PR brings all the changes from the new Metal APIs. During the
review pay special attention to the changes done in the Protocols in
order to add tvOS support.
The main problem we have had doing this PR is that tvOS was not done on
time before the NET branching, that left us with a lot of memebers that
were NOT added in tvOS that are abstract on dotnet, which has left use
in a pickle.
Lets use the following code as an example.
Code found before this commit:
```csharp
[Mac (11, 0), iOS (14, 0), NoTV]
[MacCatalyst (14, 0)]
#if NET
[Abstract]
#endif
[Export ("accelerationStructureCommandEncoder")]
IMTLAccelerationStructureCommandEncoder CreateAccelerationStructureCommandEncoder ();
```
A naive approach would be to add just the tvOS suppor as follows:
```csharp
[Mac (11, 0), iOS (14, 0), TV (16,0)]
[MacCatalyst (14, 0)]
#if NET
[Abstract]
#endif
[Export ("accelerationStructureCommandEncoder")]
IMTLAccelerationStructureCommandEncoder CreateAccelerationStructureCommandEncoder ();
```
The above change represents and API braking change on the donet tvOS dll
because it adds a new Abstrtact members, so this is no an acceptable
solution.
There is a second naive approach we can take which is as follows:
```csharp
[Mac (11, 0), iOS (14, 0), TV (16,0)]
[MacCatalyst (14, 0)]
#if NET &!TVOS
[Abstract]
#endif
[Export ("accelerationStructureCommandEncoder")]
IMTLAccelerationStructureCommandEncoder CreateAccelerationStructureCommandEncoder ();
```
Yet again, the naive approach has an issue with it. In this case, all
the extension methods that are generated for tvOS (something the
generator writes when methods are not abstract) will be decorated with
availability attributes for all the other platforms, which is incorrect
and will make developers life worse.
That leaves us with the following approach:
```csharp
#if NET
#if !TVOS
[Mac (11, 0), iOS (14, 0), NoTV, MacCatalyst (14, 0)]
[Abstract]
#else
[NoMac, NoiOS, TV (16,0), NoMacCatalyst]
#endif
#else
[Mac (11, 0), iOS (14, 0), TV (16,0), MacCatalyst (14, 0)]
#endif
[Export ("accelerationStructureCommandEncoder")]
IMTLAccelerationStructureCommandEncoder CreateAccelerationStructureCommandEncoder ();
```
With the above change, we do not add an abstract method in tvOS and we
only add the tvOS abailabity attribute to the extension methods, and use
NoiOS etc for all the other platforms.
The change had to be done to ALL methods that added tvOS support. The
good news are that our cecil tests and our introspection tests catch the
two naive approaces :)
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Haritha Mohan <harithamohan@microsoft.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
As soon as we moved to have a build of the generator that used dotnet we
opened the door to a number of developer life improvements. The very
first one of those is the poissibility to attach the dotnet debugger to
the bgen process and that way be able to debug.
In order to do that, this PR has changed two small things:
1. Added code in the main method of the generator that will block the
tool until a debugger is attached.
2. Changed the csproj to add the previously mentioned code only when the
enviroment variable XAMMACIOS_DEBUGGER is set. This way the code does
not reach our customers.
A README has been added explaining how to debug the processes via Visual
Studio. Any other IDE that support the dotnet debugger can be used this
way.
<img width="1075" alt="Screenshot 2023-12-03 at 19 10 18"
src="https://github.com/xamarin/xamarin-macios/assets/2190086/dbafc570-7c43-419f-977e-ace66f5561ac">
---------
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Similar to https://github.com/xamarin/xamarin-macios/pull/19529 we need
this for all the avfoundation to be landed.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
* Convert xharness.csproj and Xharness.Tests.csproj to .NET/sdk-style projects.
* Fix numerous nullability issues that came up.
* Adjust Make logic to do the correct thing now that the executable is named differently.
* Port usage of WebClient to HttpClient, since WebClient is deprecated.
* Find an alternative solution to System.Web.MimeMapping.GetMimeMapping, which
doesn’t exist in .NET.
* Fix misc other warnings and errors.
This PR introduces the LibraryManager and LibraryInfo and integrates them into BindingTouch.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Remove the need to pass the BT. More importantly fix an issue with the
errors when more than one attribute was expected. The eng that wrote the
code did not consider translations, and therefore the current errors
seen by a non-english speaker will result in part of the error in her
native language and the rest in english. On top of that, in english the
error is broken with words repited or broken sentences.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
It seems targets are ran in a different order in .NET 9, which means that we
ran into a different one that the one we expected. So fix that error, which
means we're now getting the error the test is checking for again.
Fixes:
Xamarin.Tests.DotNetProjectTest.InvalidArchProperty(TVOS,"MtouchArch","arm64"): Error count
Expected: 1
But was: 2
Xamarin.Tests.DotNetProjectTest.InvalidArchProperty(MacCatalyst,"MtouchArch","x64"): Error count
Expected: 1
But was: 2
Xamarin.Tests.DotNetProjectTest.InvalidArchProperty(MacOSX,"XamMacArch","x64"): Error message
Expected string length 172 but was 50. Strings differ at index 0.
Expected: "The property 'XamMacArch' is deprecated, please remove it fro..."
But was: "Could not parse TargetArchitectures 'x64'\n "
-----------^
Xamarin.Tests.DotNetProjectTest.InvalidArchProperty(iOS,"MtouchArch","armv7s"): Error count
Expected: 1
But was: 2
Also improve error reporting a bit.
It uses reflection, so it upsets NativeAOT, so just move it to cecil-test instead.
This will make it run faster, and also more predictable (it's supposed to
check all types, but types in monotouch-test may have been linked away).
Ref: https://github.com/dotnet/runtime/issues/95444
Closes#19505
We transform `[Preserve(AllMembers = true)]` into
`[DynamicDependency(DynamicallyAccessedMemberTypes.All, typeof(T))]`.
There is difference between which members are preserved in these two
cases. The `DynamicallyAccessedMemberTypes.All` preserves many more,
especially nested types and their members. This manifested with the
`IL3050` AOT analysis warning we got from ILC when building any app:
1. `NSObject_Disposer` has `[Preserve(AllMembers = true)]`
2. `NSObject_Disposer` is a subclass of NSObject
3. `NSObject` has nested enums `Flags` and `XamarinGCHandleFlags`
4. the base class `Enum` has a public static method `GetValues(Type)`
5. the `GetValues` method is annotated with `RequiresDynamicCode` and
ILC produces a warning because even though it isn't used anywhere in the
codebase, it could be used via reflection
I changed two things when transforming Preserve:
- For enums, we only need to preserve public fields. We especially want
to avoid `PublicMethods` since that would preserve public methods in the
base class which includes the `GetValues(Type)` method.
- For other types, I list explicitly the member types that should be
preserved instead of using `All`.
- The code is verbose, but in the end, I chose the explicit list instead
of `All ^ PublicNestedTypes ^ NonPublicNestedTypes` since that would
automatically include any new flag added to the enum in the future.
This pull request updates the following dependencies
## From https://github.com/dotnet/installer
- **Subscription**: 80cb9ffd-f92f-4fc8-9f8b-08dbca46abfb
- **Build**: 20231128.14
- **Date Produced**: November 28, 2023 6:11:05 PM UTC
- **Commit**: 822071c28a37cfcbf2b32077b6983e1c666160e5
- **Branch**: refs/heads/release/8.0.1xx
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 8.0.101-servicing.23572.5 to 8.0.101-servicing.23578.14][2]
- **Microsoft.NET.ILLink.Tasks**: [from 8.0.0 to 8.0.0][3]
- **Microsoft.AspNetCore.App.Ref**: [from 8.0.0-rtm.23524.5 to 8.0.0][4]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0 to 8.0.0][3]
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100**: [from 8.0.0 to 8.0.0][5]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0 to 8.0.0][3]
[2]: 35587e8180...822071c28a
[3]: https://dev.azure.com/dnceng/internal/_git/dotnet-runtime/branches?baseVersion=GC488a8a3521&targetVersion=GC5535e31a71&_a=files
[4]: https://dev.azure.com/dnceng/internal/_git/dotnet-aspnetcore/branches?baseVersion=GCb0c12dfb32&targetVersion=GC3f1acb5971&_a=files
[5]: 51bf18a2e2...2406616d0e
## 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 to 8.0.0 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 8.0.0-rtm.23524.5 to 8.0.0 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NETCore.App.Ref**: from 8.0.0 to 8.0.0 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100**: from 8.0.0 to 8.0.0 (parent: Microsoft.NETCore.App.Ref)
- **Microsoft.NETCore.App.Ref**: from 8.0.0 to 8.0.0 (parent: Microsoft.Dotnet.Sdk.Internal)
Rolf Bjarne Kvinge
dotnet-maestro[bot]
Manuel de la Pena
Michael Cummings (MSFT)
dustin-wojciechowski
Šimon Rozsíval