Change all null checking expressions to use 'is null' and 'is not null'
instead of '== null' and '!= null'.
This was mostly done with sed, so code can probably be improved in many
other ways with manual inspection, but that will come over time.
Also add code to the autoformat script to automatically fix these issues in the future.
In .NET, we changed the API for creating a NSTextList with a specified
NSTextListMarkerFormats, making NSTextListMarkerFormats a strongly typed enum,
and not allowing any other value except those in NSTextListMarkerFormats.
This was a mistake, because NSTextList can be created with other format values
than those available in NSTextListMarkerFormats.
So fix this by:
* Adding another NSTextListMarkerFormats enum value that specifies that the
actual format is a custom one (NSTextListMarkerFormats.CustomString).
* Resurface an 'NSTextListMarkerFormats(string)' constructor that can be used
to create an NSTextListMarkerFormats with a custom string.
* Add a NSTextListMarkerFormats.CustomMarkerFormat property that always
retrieves the underlying string value for the format.
* Add a NSTextListOptions.None enum value, which means no options (since
NSTextListOptions is a set of flags, it should be possible to specify no
flags).
* Add two convenience constructors that don't take a NSTextListOptions value,
defaulting to NSTextListOptions.None.
* Add tests!
Fixes https://github.com/xamarin/xamarin-macios/issues/15766.
We recently tried to fix NSDate's conversion operators with DateTime
(3c65ab1756), but unfortunately a corner case
was missed.
The new approach in the above-mentioned commit would get the individual
date/time components for a given date and use the appropriate constructor for
the other type to re-construct the date/time in question.
However, one case was missed: when converting from NSDate to DateTime, we'd
get a fractional number of milliseconds. This fractional number could be
something like 999.99 milliseconds, and when converting that to the int the
DateTime constructor expected for the number of milliseconds, then DateTime
would throw an exception, because the number of milliseconds could only be
between 0 and 999.
I've solved this by not using floating-point math in the computations. We're
now getting the number of nanoseconds from the NSDate (which is a natural
number, and represents the total number of nanoseconds less than a whole
second), and then converting that to the number of milliseconds, microseconds
and ticks that can be used with DateTime using integral math. Unfortunately
DateTime doesn't have a constructor that takes the remaining number of ticks
after all the other fields have been provided, but that can be added
afterwards.
I've also made a few other improvements:
* Improve the validation for the NSDate -> DateTime conversion to detect BC
dates by using the NSDate's Era component (to throw because DateTime only
supports AC dates). Also don't allow a tick later than year 10.000 (DateTime
only supports up to a tick before year 10.000) - but explicitly support
exactly year 10.000, and convert it to DateTime.MaxValue (this is because
due to precision errors NSDate can't actually express 'a tick before year
10.000', it ends up being rounded up to year 10.000 exactly). This means
there are no more magical values in the range validation checks.
* Increase precision in the DateTime -> NSDate conversion by starting with the
sub-second amount of ticks from the DateTime instance (instead of the number
of milliseconds). This allows us to compute the nanoseconds NSDate expects
with much higher precision.
* More tests!
Fixes this test:
MonoTouchFixtures.Foundation.DateTest.DateTimeToNSDate : 2 ms
[FAIL] Precision32022 : System.ArgumentOutOfRangeException : Valid values are between 0 and 999, inclusive.
Parameter name: millisecond
at System.DateTime..ctor (System.Int32 year, System.Int32 month, System.Int32 day, System.Int32 hour, System.Int32 minute, System.Int32 second, System.Int32 millisecond, System.DateTimeKind kind) [0x0002d] in <4d40c65adfc14d7fb19bad9310f3eb2a>:0
at Foundation.NSDate.op_Explicit (Foundation.NSDate d) [0x000b8] in <9cb1e1018c034b75ba5f4ed7b83ba2f2>:0
at MonoTouchFixtures.Foundation.DateTest.Precision32022 () [0x0000c] in <c44b5df5f7b84b69b737e9fd61bddaed>:0
at (wrapper managed-to-native) System.Reflection.RuntimeMethodInfo.InternalInvoke(System.Reflection.RuntimeMethodInfo,object,object[],System.Exception&)
at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0006a] in <4d40c65adfc14d7fb19bad9310f3eb2a>:0
Fixes https://github.com/xamarin/maccore/issues/2632.
Date and time is difficult.
Ref: https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca
Ref: the rest of internet...
Update conversions from `NSDate` to `DateTime` and `DateTime` to `NSDate` to use date components instead of `SecondsSinceReferenceDate`.
The number of seconds since reference date is inconsistent between `NSDate` and `DateTime`. See the associated bug - converting `DateTime` 1/1/1 to `NSDate` ends up giving you an `NSDate` a couple days off :(
Fixes https://github.com/xamarin/xamarin-macios/issues/6993.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Implemented the interfaces for NSOperatingSystemVersion, can now compare
instances and check for equality using operators.
Fixes#15721
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
For NSArray, implement:
* A ToArray () method that returns an NSArray[].
* A ToArray<T> () method that returns a T[].
* The IEnumerable<NSObject> interface.
For NSArray<T>, implement:
* A ToArray () method that returns a T[].
This should make NSArray much better to work with from managed code.
Context: dotnet/runtime#68610
Context: https://github.com/xamarin/xamarin-android-tools/commit/0be567a9
In Mono and .NET prior to .NET 8, the
[`System.Environment.SpecialFolder`][0]`.Personal` enum value would refer to
`$HOME` on Unix platforms.
This will be changing in .NET 8, such that
`Environment.SpecialFolder.Personal` will instead refer to
`$XDG_DOCUMENTS_DIR` (if set) or `$HOME/Documents`. This is for "semantic
compatibility" with .NET on Windows.
Replace usage of `Environment.SpecialFolder.Personal` with
`Environment.SpecialFolder.UserProfile`, so that our code continues to work as
expected under .NET 8.
[0]: https://docs.microsoft.com/en-us/dotnet/api/system.environment.specialfolder?view=net-6.0
The headers do not say that a null parameter is allowed, but the
documentation and tests state otherwise:
https://developer.apple.com/documentation/foundation/nsurl/1572047-urlwithstring
The URL string with which to initialize the NSURL object. Must be a URL that conforms to RFC 2396. This method parses URLString according to RFCs 1738 and 1808.
* Using `NativeHandle` avoids implicit casts [1]
* Do not expose `IntPtr` as the type for the `SuperClass` handle
[1] likely not an issue with JIT/AOT optimization, less sure for the
interpreter. No harm in not having those in the product assembly.
Fixes race condition where finalized objects are resurrected by the finalizer and for a brief moment `Runtime.TryGetNSObject`/`Runtime.GetNSObject` would return them even though a new instance is supposed to be used. In multi-threaded scenarios this would result in reused objects (same native handle) to suddenly become invalid when the UI thread processes the delayed finalization.
Fixes#13921
* Use 'ObjCException' instead of 'MonoTouchException' as the managed exception
type wrapping an NSException for all platforms in .NET (that was already the
case for macOS, so no change there).
* Make the ObjCException class behave like the MonoTouchException class does.
* Move the ObjCException type to the ObjCRuntime namespace in .NET.
Fixes https://github.com/xamarin/xamarin-macios/issues/13855.
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
* Use the native `NSStringFrom*` API so we can, eventually, use the
native code to parse them from `NSString` and also ensure increased
compatibility with any code that expects the native string representation
* Add unit tests for `ToString` methods
Also use [`System.HashCode`](https://docs.microsoft.com/en-us/dotnet/api/system.hashcode?view=net-6.0) to generate the hash code
It's our own enum, and all the API using it have been obsoleted/removed.
There doesn't seem to be any other usage of it on GitHub either (only our own
source code and documentation).
* [Xcode13.2] Bump to Xcode 13.2 RC (#13497)
* [Xcode13.2] Bump to Xcode 13.2 Beta 2
Breaking changes addressed for legacy
* HomeKit
* CallKit
* CoreLocation
* [xcode13.2] Bump to Xcode 13.2 RC and apply feedback
* [AppKit] Fix missing Notifications
* Fix xtro
* [xcode13.2] Bump versions and use stable Xcode 13.2
* [monotouch-tests] Make TestAddingByComponents work on the last day of the year
Happy New Year!!
* NO BOM PLZ!
Remove Runtime.Arch and ObjCRuntime.Arch from Mac Catalyst, because they don't
apply for a Mac Catalyst app (which is neither a simulator environment, nor a
device environment).
This means that code using these APIs will have to be re-evaluated to
determine what's the correct behavior for Mac Catalyst.
Also update our tests accordingly.
Fixes https://github.com/xamarin/xamarin-macios/issues/10312.
* [monotouch-test] Ignore a few tests in non-ARM64 simulators.
Some tests fail when running on an M1, but in a x64_86 mode, so just ignore
those unless we're running on ARM64 (this will currently exclude them on
x86_64 hardware too, but that'll eventually not be a problem anymore when
there's no more x86_64 hardware, and just checking for ARM64 is easier than
checking for x86_64 mode on an ARM64 CPU).
* Make more legacy projects unsafe.
Removes the following warning during the builds:
```
warning CS8767: Nullability of reference types in type of parameter 'host' of 'bool NSHost.Equals(NSHost host)' doesn't match implicitly implemented member 'bool IEquatable<NSHost>.Equals(NSHost? other)' (possibly because of nullability attributes)
```
Test was added to ensure that we did not throw an exception.
Modifying the test to use UTC datetimes instead of local datetimes + specify
the timezone for the NSCalendar to make the results predictable everywhere and
at all times.
Fixes https://github.com/xamarin/maccore/issues/2471.
Rolf Bjarne Kvinge
Whitney Schmidt
Haritha Mohan
Chris Hamons
Manuel de la Pena
Sebastien Pouliot
Filip Navara
Marius Ungureanu
Alex Soto