https://bugzilla.xamarin.com/show_bug.cgi?id=53076
When [Async] was used on a member of a [Model][Protocol][Basetype]
interface the ModelClass ended up with additional FooAsync methods that
are not really part of the Model.
This commit removed any instances of FooAsync members from model classes
and also fixes any breaking changes in the currently bound classes.
Added test case using Model.
build diff:
https://gist.github.com/dalexsoto/75cb8424f2462bd6b513049f00bba6a8
Currently we get a CS2019 warning whenever we use AsyncAttribute
because we ignore the `result` variable on methods whose return
type is != `void` which is the expected behaviour.
This is specially more annoying on third party bindings,
the generated code did not disable this warning so you get
an "unfixable" warning on the generated code and the user
has no way to fix this on their own.
We now disable and restore CS2019 in the generated code as needed.
Nobody likes warnings that are not their fault.
Added unit test.
Build diff:
https://gist.github.com/dalexsoto/6f57d3f84b039b9fda863e2f8cfcf365
Simplify mac tests by using different variables for the various flavors of mac
generators, and use these new flavors so that all tests pass when using the
IKVM-based bgen.
* [generator] Fix bug 42742 The advice attribute doesn't make it to the generated code
https://bugzilla.xamarin.com/show_bug.cgi?id=42742
The Advice attribute used in our bindings was not making
into the generated code. This fixes it.
Also added unit test for it
* [generator] Merged PrintFooAttributes into one
Merged PrintPlatformAttributes, PrintPreserveAttribute and
PrintAdviceAttribute into a single method PrintAttributes.
This is due to sometimes we call three times in a row the same method:
```csharp
PrintPlatformAttributes (pi.GetGetMethod ());
PrintPreserveAttribute (pi.GetGetMethod ());
PrintAdviceAttribute (pi.GetGetMethod ());
```
We now do
```csharp
PrintAttributes (pi, platform:true, preserve:true, advice:true);
```
Also removed a not used instance (internal field) of AdviceAttribute
https://bugzilla.xamarin.com/show_bug.cgi?id=52570
In some cases you will find **static** members inside categories like in the following example:
```objc
@interface FooObject (MyFooObjectExtension)
+ (BOOL)boolMethod:(NSRange *)range;
@end
```
This will lead to an **incorrect** Category C# interface definition:
```csharp
[Category]
[BaseType (typeof (FooObject))]
interface FooObject_Extensions {
// Incorrect Interface definition
[Static]
[Export ("boolMethod:")]
bool BoolMethod (NSRange range);
}
```
This is incorrect because in order to use the `BoolMethod` extension you need an instance of `FooObject` but you are binding an ObjC **static** extension, this is a side effect due to the fact of how C# extension methods are implemented.
The only way to use the above definitions is by the following ugly code:
```csharp
(null as FooObject).BoolMethod (range);
```
The recommendation to avoid this is to inline the `BoolMethod` definition inside the `FooObject` interface definition itself, this will allow you to call this extension like it is intended `FooObject.BoolMethod (range)`.
```csharp
[BaseType (typeof (NSObject))]
interface FooObject {
[Static]
[Export ("boolMethod:")]
bool BoolMethod (NSRange range);
}
```
We will issue a warning (BI1117) whenever we find a `[Static]` member inside a `[Category]` definition. If you really want to have `[Static]` members inside your `[Category]` definitions you can silence the warning by using `[Category (allowStaticMembers: true)]` or by decorating either your member or `[Category]` interface definition with `[Internal]`.
* [tests][generator] Port XI/Classic tests to XI/Unified.
* [tests][generator] Comment out code triggering previously unknown bugs.
These tests makes the generator fail:
error BI0000: Unexpected error - Please file a bug report at http://bugzilla.xamarin.com
System.NullReferenceException: Object reference not set to an instance of an object
at Generator.GetSetterExportAttribute (System.Reflection.PropertyInfo pinfo) [0x0002e] in /work/maccore/master/xamarin-macios/src/generator.cs:1981
at Generator.Go () [0x007e3] in /work/maccore/master/xamarin-macios/src/generator.cs:2162
at BindingTouch.Main2 (System.String[] args) [0x010b2] in /work/maccore/master/xamarin-macios/src/btouch.cs:435
at BindingTouch.Main (System.String[] args) [0x0001d] in /work/maccore/master/xamarin-macios/src/btouch.cs:77
at System.Environment.get_StackTrace () [0x00000] in /work/maccore/master/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/src/mono/mcs/class/corlib/System/Environment.cs:321
at ErrorHelper.ShowInternal (System.Exception e) [0x000dc] in /work/maccore/master/xamarin-macios/src/error.cs:200
at ErrorHelper.Show (System.Exception e) [0x00027] in /work/maccore/master/xamarin-macios/src/error.cs:151
at BindingTouch.Main (System.String[] args) [0x0002b] in /work/maccore/master/xamarin-macios/src/btouch.cs:79
This has been filed as https://bugzilla.xamarin.com/show_bug.cgi?id=52664.
* [tests][generator] Comment out code triggering previously unknown bugs.
This has been filed as https://bugzilla.xamarin.com/show_bug.cgi?id=52665.
Fixes this warning:
Makefile:163: warning: overriding commands for target `virtualwrap'
Makefile:40: warning: ignoring old commands for target `virtualwrap'
* [generator] Have WrapAttribute generate virtual members
WrapAttribute now has a boolean optional parameter named isVirtual,
this instructs the generator to add the virtual keyword to generated
members.
This is useful when fixing breaking changes so we can keep the wrong
signature generated instead of having manual code files.
* [docs] Add docs about virtual to WrapAttribute
* [generator] Add BindAs support for NSValue and NSNumber
https://trello.com/c/RYCPEnkh
The intent of BindAs attribute is to have a binding definition as
[return: BindAs (typeof (bool?))]
[Export ("boolMethod:")]
NSNumber BoolMethod (int arg1);
and our generator outputs
[Export ("boolMethod:")]
public virtual global::System.Nullable<bool> BoolMethod (int arg1) { ... }
So we internally do the NSNumber <-> bool conversion, this also
applies to properties, parameters and methods.
* [generator] Fix a small formating issue
* [tests] Add BindAsAttribute generator tests
* [generator] Implement @spouliot's feedback
* [tests] Add BI1048 and BI1049 error tests for [BindAs]
* [generator] Implement Rolf's suggestion to avoid almost all string comparisons in [BindAs] for types
* [generator] Add BindAs support for smart enums and arrays with tests
* [generator] Some code clean up and implementation of PR feedback
* [generator] Add Protocol|Model checks and tests also a NRE check in NSArray creator
BindAs attribute cannot be used in Protocol|Model interfaces
* [generator] Add NSNumber <-> Enum support
* [docs] add BindAs documentation
* [docs] Implement documentation feedback for BindAs
Considering the following binding code:
public enum HMAccessoryCategoryType {
[Field ("HMAccessoryCategoryTypeGarageDoorOpener")]
DoorOpener,
GarageDoorOpener = DoorOpener,
}
We must
1. Ensure that `HMAccessoryCategoryType.DoorOpener.GetConstant () ==
HMAccessoryCategoryType.GarageDoorOpener.GetConstant ()`;
This is done by using the numeric value of the enum member (instead of the name)
2. Ensure that `HMAccessoryCategoryTypeExtensions.GetValue ("HMAccessoryCategoryTypeGarageDoorOpener")`
always return the same enum value, i.e. it can **not** change between
XI versions (e.g. due to reflection ordering) as it could break
comparison code;
This is done by only adding a map to the member that has a [Field] and
means that:
2.1. the _favorite_ enum member should be the one with the [Field]; and
2.2. a [Field] value can only be used once per enum (or else we report
an BI1046 error). This also solve the duplicate code generation for
the constant loading code;
Reference:
* https://bugzilla.xamarin.com/show_bug.cgi?id=46285
* [generator] Fix bug 43579 - Generator emits invalid code when using the same method name (overload) in @delegates using events and C# delegates
https://bugzilla.xamarin.com/show_bug.cgi?id=43579
Bug Description:
Generator will emit invalid code when using the same name (overload)
in a method inside a @delegate (protocol) that is decorated
either with EventArgs or DelegateName
-----------------------------------------------------------------
This commit introduces a new attribute named DelegateApiNameAttribute
which mimics the EventNameAttribute but for delegate properties in
host classes
It is used to specify the delegate property name that will be created when
the generator creates the delegate property on the host
class that holds events and delegates.
This is really useful when you have two overload methods that makes
sense to keep them named as is but you want to expose them in the host class
with a better given name.
example:
interface SomeDelegate {
[Export ("foo"), DelegateApiName ("Confirmation"), DelegateName ("Func<bool>"), DefaultValue (false)]
bool Confirm (Some source);
}
Generates propety in the host class:
Func<bool> Confirmation { get; set; }
This also introduces two new BIXXXX errors:
- BI1043 Repeated overload {mi.Name} and no [DelegateApiNameAttribute]
provided to generate property name on host class.
- BI1044 Repeated name '{apiName.Name}' provided in [DelegateApiNameAttribute].
Which provides an error instead of generating invalid C# code.
Generator test included :D
* [docs] Added DelegateApiNameAttribute and IgnoredInDelegateAttribute docs
Also added Protocol where Model was used in our docs so we do not
misslead customers about it
Alex Soto
Rolf Bjarne Kvinge
Alex Soto
Sebastien Pouliot
Manuel de la Pena