Apple decided to expose most (but not all) `CIFilter` using protocols
(instead of weakly named dictionaries). Most of this maps well with
our strong bindings but there are cases where we:
* missing some properties (easy, there were added); or
* used a different types [1] and that requires new members / obsoletion
A few other API were also added in Xcode 11 (nothing in 11.1 or 11.2) and
included in this PR.
New introspection tests were also added to minimize the risk that
the API and generator changes produced incorrect code. This lead
to the finding of some missing API (in particular `Output*` properties)
that were added.
[1] Often ours are better (using `float` for a `bool` value is not
optimal) but we do not have `[BindAs]` for protocols :( to _fix_ them
Note: this replace draft PR https://github.com/xamarin/xamarin-macios/pull/7120 but it's has quite a bit of changes in filter generation (inlining protocols) and that affected bindings too.
This includes:
* 32-bit version of Xamarin.Mac.dll and OpenTK.dll
* XamMac.dll and XamMac.CFNetwork.dll
* 32-bit versions of the runtime libraries (libxammac.a and friends).
* 32-bit version of the partial static library for Xamarin.Mac.
* Classic support in the generator.
We still ship a few Classic files so that Visual Studio for Mac continue to detect that Xamarin.Mac is installed (otherwise VSfM won't open Classic projects, which makes it impossible to use the migration wizard).
This makes our build slightly faster.
Partial fix for #6300.
* [mtouch/mmp] Split out the RunCommand[Async] methods to a separate file so that the generator can reuse more easily.
* [generator] Show proper errors when failing to compile something.
* Fix grammar
The `[NullAllowed]` attribute should not be allowed on methods but it
could break existing binding projects.
Historically it was used on property setters. However using the attribute
on _other_ methods can be misleading, e.g. should it apply to all
parameters, the return value... and its presence/action can be
misinterpreted in code reviews leading to binding bugs.
reference: https://github.com/xamarin/xamarin-macios/issues/5416
* [generator] Teach generator about WrapAttribute on Getters and Setters
https://bugzilla.xamarin.com/show_bug.cgi?id=57870
`WrapAttribute` can now be used in property getters and setters,
this allows to Wrap virtually anything the way you need, for example
smart enums, consider the following API definition:
```csharp
// Smart enum.
enum PersonRelationship {
[Field (null)]
None,
[Field ("FMFather", "__Internal")]
Father,
[Field ("FMMother", "__Internal")]
Mother
}
```
```csharp
// Property definition.
[Export ("presenceType")]
NSString _PresenceType { get; set; }
PersonRelationship PresenceType {
[Wrap ("PersonRelationshipExtensions.GetValue (_PresenceType)")]
get;
[Wrap ("_PresenceType = value.GetConstant ()")]
set;
}
```
* Fix Feedback
* Fix doc error
* Update error message
When a method signature contains any ref/out parameters
it is a hint that this method is not a candidate to be
used with [Async] we now error BI1062 in the generator.
The reason of an error instead of a warning is that we
currently generate not compilable code when ref/out is
used on the method signature or in the signature of the
delegate (completion handler), it is very unlikely we are
breaking someone now that we emit an error instead of broken
code.
* Fix Anchor and Clarify the addition of BI1117 Warning into docs/website/generator-errors.md
BI1117 Warning documentation was missing from docs/website/generator-errors.md
so I added it.
* [generator] Improve BI1014 - include name of unsupported field and update valid types on docs, fixes bug 57094.
https://bugzilla.xamarin.com/show_bug.cgi?id=57094
* Implement feedback
* fix error message
* More feedback
This is the first step for documenting the error messages in the generator:
create a document for the error messages.
The entries in the document are the same as the ones listed in the error.cs
file (which I've now removed to prevent duplication), with some very minor
editing.
The document is not yet published to the documentation repository (since this
is just the first step).