Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
When I pass `null` as a parameter to `NSApplication.SharedApplication.Terminate()`, an ArgumentNullException is thrown. IMHO, this is undesirable behavior, as passing a `null`/`nil` sender is a common Cocoa idiom for when the sender is unimportant, and all references to it should be ignored by the callee.
You are correct, the header notes the selector as:
- (void)terminate:(nullable id)sender;
To give you some backstory explaining the bug:
- Until recently, Apple's headers did _not_ note which items were nullable
- Thus, when binding one had to be careful to manually test when it was not clear
- By default we "fail safe" and assume null is an invalid value. We do this because a managed ArgumentNullException is easy to catch/debug for many, while a native crash, with walls of angry red text in the console, is not.
- We can add a [NullAllowed] to our bindings to fix this.
- Not every existing binding has been scrubbed since Apple introduced nullability markups
There are 202 instances of "NSObject sender" in appkit.cs which likely contain the problem without [NullAllowed], 161 without it.
Each instance will need to be checked against the headers.
@Chris you're right but this needs to be added to the xtro tests (it's on the TODO) and not a manual audit. There's too many API and Apple changes/update nullability too often to do this manually. Also other frameworks needs the same review.
That being said let's fix the requested API asap (for 15.4) and track the overall issue in a separate bug.
Yeah, that's what I was thinking actually (I prefer not to check 160+ items by hand when I can avoid it). :)
I'll fix this single item for 15.4.
https://bugzilla.xamarin.com/show_bug.cgi?id=58674 for the systemic issue
master fixed: https://github.com/xamarin/xamarin-macios/commit/6c920381ea31cf8713127aee1a520faaf67e98f9
d15-4 PR: https://github.com/xamarin/xamarin-macios/pull/2472