We are doing the following:
1. Adding the rgen directory with the following solutions:
* Analyzer: Analyzer that will catch errors in the bindings. At the
moment it provides a single error when the BindingTypeAttribute is used
in a nont partial type.
* Analyzer Tests: Allows tests for the analyzer.
* Analyzer Sample: Sample project to test the analyzer.
* Code Generator: A code generator that adds the BindingTypeAttribute to
the compilcation.
* Code Generator Tests: Allows tests for the generator.
* Code Sample: Sample project for the code generator.
2. Make rule to build the roslyn code generator.
3. Makefile changes to add the code generator as part as the second
compilation of the bindings.
This changes add the starting gounds to move to roslyn.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Alex Soto <alex@soto.dev>
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>
Make it appropriately quiet, and pass the project.
This makes the run-tests target work when there's also a .sln in the same
directory (which gets created automatically when opening the project in
VSCode).
Some changes:
1. Move all the static attr related methods to the attr factory.
2. Make it simpler to see the diff between NET and not by using a
partial class.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Naming could be problematic when generating code, move the logic out of
the generator class to a helper class whose only job is to name classes
and keep track of names.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Moved the extension methods to their own file and enabled nullable.
Fixed the following underlying bug:
The extension method that creates a valid parameter named does not do
the right thing in the following cases:
1. When the starting illegal char is NOT a number. It will prepend @
fixing nothing. Example " OHOH" to "@ OHOH"
2. When the illegal chars is in the middle of the param name. Example
"OH OH" to "@OH OH"
I have fixed the method to return null in those ocassions (we will need
to enable nullability later in the generator, is too much for this PR).
Tests have been added to ensure we do not have such an issue again.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
This is the first part of a 2 or more changes that will allow the APIs
to use ? as a way to mark a nullable field, parameter, property and
return method.
The way it works follows the documentation from the runtime that can be
found here:
https://github.com/dotnet/roslyn/blob/main/docs/features/nullable-metadata.md
The tldr; of the documentation is as follows:
1. If we are looking at a value type, the compiler converts int? into
Nullable<int>. This was already considered in the old code.
2. If we are inspecting a generic type we have to look for the
information in two different attributes added by the compiler: -
NullableAttribute: Each type reference in metadata may have an
associated NullableAttribute with a byte[] where each byte represents
nullability: 0 for oblivious, 1 for not annotated, and 2 for annotated.
- NullableContextAttribute is valid in metadata on type and method
declarations. The byte value represents the implicit NullableAttribute
value for type reference within that scope that do not have an explicit
NullableAttribute and would not otherwise be represented by an empty
byte[].
The API is very similar to that provided by dotnet6 but it allows us to
support classic. The move to the dotnet6 API should not be hard and
probably can be done by an IDE.
Once this API lands we will have to find the old usages of the check for
nullability and combine both. This new API should fix several issues we
have with nullability and nullability + generics.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
* Update dependencies from https://github.com/dotnet/installer build 20210530.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21274.3 -> To Version 6.0.100-preview.6.21280.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.5.21271.1 -> To Version 6.0.100-preview.6.21277.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Bump to MSBuild.StructuredLogger v2.1.500 to get support for log format v14.
* [tests] Skip code that needs System.ComponentModel.Composition or System.Json due to #11710.
Ref: https://github.com/xamarin/xamarin-macios/issues/11710
* [tests] Adjust logic to find MSBuild items after the last MSBuild.StructuredLogger update.
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Bump to .NET 6.0.100-preview.3.21152.10
* Bump to 6.0.100-preview.3.21152.10.
* Bump to 6.0.100-preview.3.21161.7.
* Bump to .NET 6.0.100-preview.3.21161.23.
* [dotnet-linker] Bump ILink and use the supported method of getting an assembly's location.
* Bump to MSBuild.StructuredLogger 2.1.364 to get support for newer binlog versions.
* Fix build failure
Fixes:
TestHelpers/BuildEngine.cs(161,24): error CS0433: The type 'ProjectEvaluationFinishedEventArgs' exists in both 'Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' and 'StructuredLogger, Version=2.1.0.0, Culture=neutral, PublicKeyToken=d4c7181801cb6448' [/Users/builder/azdo/_work/1/s/xamarin-macios/tests/msbuild/Xamarin.MacDev.Tests/Xamarin.MacDev.Tests.csproj]
* Update parsing binlog properties.
* Be more defensive.
* [tests] Make sure the InternalsVisibleToAttribute constructor isn't linked away.
* [tests] Implement better printing of binlogs.
The latest MSBuild.StructuredLogger made some internal changes to the Message
property which confuses some of our test logic. So implement manual printing
of the log entries that we care about to make sure they conform to the
expected format by the tests (the output is mimicing what 'msbuild /v:diag
foo.binlog' would show).
* Bump .NET to 6.0.100-preview.2.21114.3.
* [dotnet-linker] Several steps are now gone, so load our custom step before the new first step (MarkStep).
* [dotnet-linker] Dump the current steps if we fail to call InsertBefore/InsertAfter.
* [dotnet-linker] Load the CollectAssembliesStep as the first step, and make it load every assembly.
* [dotnet] Set InvariantGlobalization=true because that's the only thing .NET supports for now.
* [dotnet-linker] Use recommended workaround for linker's inability to do load assemblies in custom step.
* [tests] Bump version of MSBuild.StructuredLogger to get support for new log version.
Otherwise this happens in tests that read binary logs:
System.NotSupportedException : Unsupported log file format. Latest supported version is 9, the log file has version 10.
* [introspection] Ignore P/Invokes to QCall for LogThreadPool* P/Invokes.
* [dotnet-linker] Inject a dummy implementation of mono_config_parse_memory as a temporary solution for mono's removal of the same method.
* [src] Build the .NET version of our product assemblies using a .NET 5 BCL.
We're not shipping the .NET product assemblies in any stable release, so we
can use a preview version of the .NET 5 BCL.
Also:
* Add all the nuget feeds we need to the top-level NuGet.config, even for .NET
5/6, there shouldn't be any conflicts with stable feeds since we use exact
version numbers.
* Generate a top-level global5.json which is copied to every directory that
needs a .NET 5 global.json (overriding the .NET 3.1 global.json in the root
directory).
* Use the expected dotnet binary during our local build.
* [tests] Fix the bgen tests to use .NET 5.
* [xharness] Set the current directory to the project directory when running .NET tests.
This way we end up using the dotnet version that's configured in global.json for the tests.
Manuel de la Pena
Rolf Bjarne Kvinge
Sebastien Pouliot
dotnet-maestro[bot]