Fix these warnings:
src/Foundation/NSUrlSessionHandler.cs(71,57): warning CS3001: Argument type 'NSUrlSessionConfiguration' is not CLS-compliant
src/Foundation/NSUrlSessionHandler.cs(89,14): warning CS0618: 'NSUrlSession.FromConfiguration(NSUrlSessionConfiguration, NSUrlSessionDelegate, NSOperationQueue)' is obsolete: 'Use the overload with a 'INSUrlSessionDelegate' parameter.'
This method is called back from iOS (or tvOS) so there's no managed
reference pointing to it. However we know that if it's (private inner)
type is present it's because the callback (from native) is possible so
we can preserve the method conditionally (to the type presence).
https://github.com/xamarin/xamarin-macios/issues/5024
Unce upon a time we used a separate mono submodule for watchOS support, to make
development of watchOS support easier (we referenced mono/master, to avoid
backporting fixes for watchOS support through various release branches in
mono).
This only worked until our watchOS support became stable, since then we had to
start using a stable version of mono for watchOS support.
This means that our build support for using a separate mono clone for watchOS
support is no longer needed; and in any case it's broken because of build
changes done later.
- Fixes#4698: CGAffineTransform.Scale does not work like Swift's .scaledBy(x:y:)
(https://github.com/xamarin/xamarin-macios/issues/4698)
- 'Scale' monotouch-test now covers the new overload for the new multiplication order.
- Changed the Scale test's values so we have different values for 'x0' (it was always 0 before) and so it matches the test case from the bug report.
* Same fix for Rotate and Translate
* Refactor type map to have a separate flag field for each type instead of magic location in the array.
Refactor the type map to have a separate flag field for each type instead of a
magic location in the array. This simplifies some code, but also allows us to
introduce more flags in the future (which becomes increasingly complex if the
location in the array is to determine yet another value).
This has neglible performance impacts.
* Add a UserType flag for registered types, and use it to improve the performance for is_user_type.
Reflection in the Objective-C runtime is apparently quite slow, so try to
avoid it by computing the information we need for determining whether a
particular Objective-C type represents a user type or not in the static
registrar.
We store this information in a flag for the type in question in the type map,
and use a binary search to search the type map when needed.
This provides a significant improvement, in particular in the dontlink
scenario (probably because there are many more Objective-C types in the app,
which made Objective-C reflection slow). In fact, it somehow made the dontlink
scenario so fast that it's faster than the linkall scenario (which also
improved, but not nearly as much). While quite inexplicable, it's a consistent
result I've seen over multiple test runs.
Numbers
=======
Test case: 004283d7b6
Fix 1 refers to PR #5009.
Fix 2 refers to PR #5013.
Fix 3 refers to PR #5016.
Fix 4 is this fix.
iPad Air 2
----------
| Configuration | Before | After fix 1 | After fix 2 | After fix 3 | After fix 4 | Improvement from fix 3 to fix 4 | Cumulative improvement |
| ------------------- | ------ | ----------: | -----------: | -----------: | -----------: | ------------------------------: | ---------------------: |
| Release (link all) | 477 ms | 481 ms | 224 ms | 172 ms | 148 ms | 24 ms (14%) | 329 ms (69%) |
| Release (dont link) | 738 ms | 656 ms | 377 ms | 201 ms | 146 ms | 55 ms (27%) | 592 ms (80%) |
iPhone X
--------
| Configuration | Before | After fix 1 | After fix 2 | After fix 3 | After fix 4 | Improvement from fix 3 to fix 4 | Cumulative improvement |
| ------------------- | ------ | ----------: | -----------: | -----------: | -----------: | ------------------------------: | ---------------------: |
| Release (link all) | 98 ms | 99 ms | 42 ms | 31 ms | 29 ms | 2 ms ( 6%) | 69 ms (70%) |
| Release (dont link) | 197 ms | 153 ms | 91 ms | 43 ms | 28 ms | 15 ms (35%) | 169 ms (86%) |
When linking all assemblies, the type map has 24 entries, and when not linking
at all it has 2993 entries.
This is part 4 (the last) of multiple fixes for #4936.
The total speed-up is 69-86% (3-7x faster).
Using reflection to find these constructors is computation-intensitive, so
cache the results.
Numbers
=======
Test case: 004283d7b6
Fix 1 refers to PR #5009.
Fix 2 refers to PR #5013.
Fix 3 is this fix.
iPad Air 2
----------
| Configuration | Before | After fix 1 | After fix 2 | After fix 3 | Improvement from fix 2 to fix 3 | Cumulative improvement |
| ------------------- | ------ | ----------: | -----------: | -----------: | ------------------------------: | ---------------------: |
| Release (link all) | 477 ms | 481 ms | 224 ms | 172 ms | 52 ms (23%) | 305 ms (64%) |
| Release (dont link) | 738 ms | 656 ms | 377 ms | 201 ms | 176 ms (47%) | 537 ms (73%) |
iPhone X
--------
| Configuration | Before | After fix 1 | After fix 2 | After fix 3 | Improvement from fix 2 to fix 3 | Cumulative improvement |
| ------------------- | ------ | ----------: | -----------: | -----------: | ------------------------------: | ---------------------: |
| Release (link all) | 98 ms | 99 ms | 42 ms | 31 ms | 11 ms (26%) | 67 ms (68%) |
| Release (dont link) | 197 ms | 153 ms | 91 ms | 43 ms | 48 ms (53%) | 154 ms (78%) |
When linking all assemblies, the type map has 24 entries, and when not linking
at all it has 2993 entries.
This is part 3 of multiple fixes for #4936.
Cache the Class -> System.Type lookup in an array.
I could also have used a dictionary, but there are a couple of disadvantages
compared to the array approach:
* A dictionary would require a lock every time it's read/written to. The array
is created at launch, and after that we don't have to care about thread
safety because it's safe to do the slow lookup multiple times.
* Its memory requirements would be higher with more elements (in particular
since we'd not only need to store the Type instance, but also a boolean
determining whether it's a user type or not).
* It's ~1% slower (probably due to the lock).
Numbers
=======
Test case: 004283d7b6
Fix 1 refers to PR #5009.
Fix 2 is this fix.
iPad Air 2
----------
| Configuration | Before | After fix 1 | After fix 2 | Improvement from fix 1 to fix 2 | Cumulative improvement |
| ------------------- | ------ | ----------: | -----------: | ------------------------------: | ---------------------: |
| Release (link all) | 477 ms | 481 ms | 224 ms | 257 ms (53%) | 253 ms (53%) |
| Release (dont link) | 738 ms | 656 ms | 377 ms | 279 ms (43%) | 459 ms (62%) |
iPhone X
--------
| Configuration | Before | After fix 1 | After fix 2 | Improvement from fix 1 to fix 2 | Cumulative improvement |
| ------------------- | ------ | ----------: | -----------: | ------------------------------: | ---------------------: |
| Release (link all) | 98 ms | 99 ms | 42 ms | 57 ms (58%) | 56 ms (57%) |
| Release (dont link) | 197 ms | 153 ms | 91 ms | 62 ms (41%) | 106 ms (54%) |
When linking all assemblies, the type map has 24 entries, and when not linking
at all it has 2993 entries.
This is part 2 of multiple fixes for #4936.
Our type map has two sections: first come all the wrapper types, then all the
custom types. This means we need to sort these two sections separately, since
code elsewhere depends on this split in order to determine if a type is a
custom type or not.
We also need a minor modification in the array of skipped types, since it
contained indexes into the type map, which won't be valid after is has been
sorted. Instead store a type reference for the actual type in the array, and
use that to search the type map for the corresponding Class. This is a little
bit slower, but the results are cached in a dictionary, so it'll only happen
once for each type.
The performance is slightly slower when the type map has very few entries, but
that is repaid many times over when the number of entries go up.
Numbers
=======
Test case: 004283d7b6
iPad Air 2
----------
| Configuration | Before | After | Improvement |
| ------------------- | ------ | ------ | ------------: |
| Release (link all) | 477 ms | 481 ms | -4 ms (-0,8%) |
| Release (dont link) | 738 ms | 656 ms | 82 ms (11%) |
iPhone X
--------
| Configuration | Before | After | Improvement |
| ------------------- | ------ | ------ | ----------: |
| Release (link all) | 98 ms | 99 ms | -1 ms (-1%) |
| Release (dont link) | 197 ms | 153 ms | 44 ms (22%) |
When linking all assemblies, the type map has 24 entries, and when not linking
at all it has 2993 entries.
This is part 1 of multiple fixes for #4936.
`ContentOffset` was moved to `UIFocusItemScrollableContainer` in iOS 12.
Since it's a new protocol it's decorated as introduced in iOS 12 - but
the API was actually already available for a long time.
The _trick_ is to keep the original binding inside `UIScrollView`
so it overrides the protocol and keeps the correct availability info.
It requires adding `new` to bindings to avoid compiler warnings.
reference: https://github.com/xamarin/xamarin-macios/issues/4893
---
from @rolfbjarne
In iOS 12 this property was moved to a protocol, but that protocol's
availability attributes limits it to iOS 12, not iOS 2 where this property was
originally introduced.
This is problematic, because it means we'll throw a
PlatformNotSupportedException if someone tries to call it on 32-bit iOS.
So put the property back on UIScrollView, so that the generated code ends up
with the right availability attributes (and a correct 32-bit implementation).
https://github.com/xamarin/xamarin-macios/pull/5004
* [UIKit] UIGestureRecognizer, support a way of unsubscribing without creating cycles
This now tracks all the uses of AddTarget with delegates by recording
the Token/Selector pair and making `Dispose()` release all the linkage
as well as providing an enumerator that can be used to get all the
registered Action handlers - this can then be used with .First() and
then passed to `RemoveTarget`.
This addresses https://github.com/xamarin/xamarin-macios/issues/4190
This initial patch is here for discussion of the approach, want to
review and test this before we merge.
* Simplify code a little bit.
* Add test.
* [tests] Add an NSAutoreleasePool to make GestureRecognizerTest.NoStrongCycles happy on 32-bit.
The custom `TryGetValue` could return `true` and an `out null`. That was
fine for many items, e.g. converting `null` to `NSString` or `NSDate` is
fine.
However this cause an `NullReferenceException` when trying to create
arrays (thru `NSArray`) or converting `NSNumber` into value types.
The _normal_ `TryGetValue` behavior fixes this - and avoid extraneous
(and non-required) conversions of `null` items.
ref: https://github.com/xamarin/xamarin-macios/issues/4988
The custom `TryGetValue` could return `true` and an `out null`. That was
fine for many items, e.g. converting `null` to `NSString` or `NSDate` is
fine.
However this cause an `NullReferenceException` when trying to create
arrays (thru `NSArray`) or converting `NSNumber` into value types.
The _normal_ `TryGetValue` behavior fixes this - and avoid extraneous
(and non-required) conversions of `null` items.
ref: https://github.com/xamarin/xamarin-macios/issues/4988
`ContentOffset` was moved to `UIFocusItemScrollableContainer` in iOS 12.
Since it's a new protocol it's decorated as introduced in iOS 12 - but
the API was actually already available for a long time.
The _trick_ is to keep the original binding inside `UIScrollView`
so it overrides the protocol and keeps the correct availability info.
It requires adding `new` to bindings to avoid compiler warnings.
reference: https://github.com/xamarin/xamarin-macios/issues/4893
The selectors `suggestedInvocationPhrase` and `setSuggestedInvocationPhrase`
needs Intents.framework to be loaded into memory. Otherwise an exception
occurs:
```
Objective-C exception thrown. Name: NSInvalidArgumentException Reason: -[NSUserActivity setSuggestedInvocationPhrase:]: unrecognized selector sent to instance 0x19cb3f00
```
When the linker is enabled there's no clue (e.g. namespaces from
preserved types) that `Intents` is required to call the property.
The fix is to provide an hint that will force the linker to keep a type
(a small enum available in all platforms in this case) which tells
`mtouch` (based on the type's namespace) to instruct the native linker
(Apple's `ld`) to [weak]link the Intents.framework in the application
executable.
Note: other selections from the category works fine.
reference:
https://github.com/xamarin/xamarin-macios/issues/4894
Throw PlatformNotSupportedException for iOS API that was introduced in iOS 11+
in 32-bit mode, since that API is clearly not available in any 32-bit capable
iOS version.
This makes the 32-bit version of Xamarin.iOS.dll smaller (from 15.282.176
bytes to 14.575.616 bytes, ~700kb smaller - small enough that this makes the
dontlink test work in 32-bit mode again on device).
Fixes https://github.com/xamarin/xamarin-macios/issues/4689.
* [CoreFoundation] Make DispatchObject inherit from NativeObject to share more code.
* [CoreFoundation] Replace calls to Check () with calls to GetCheckedHandle () to reuse more code.
* [CoreFoundation] Simplify a bit by reusing code in base constructors.
* [CoreFoundation] Use Handle instead of handle.
* [CoreFoundation] Use InitializeHandle instead of setting the 'handle' field.
* [CoreFoundation] Remove temporary 'handle' field.
* [CoreFoundation] Remove needless 'unsafe' blocks.
* Reintroduce DispatchObject.Check, since it's public API.
* Bump to mono:2018-06
* Bump mono
* Updates compression to work with the public span
* Bump mono
* Fixes pointer check logic in Deflater
* Bump mono
* Fixes pointer check logic in Deflater
* Bump mono
* Bump Mono
* [runtime] always use `mono_jit_set_aot_mode` (#4491)
`mono_jit_set_aot_only` is deprecated and accidentally broke with
https://github.com/mono/mono/pull/7887
This should fix device tests with `mono-2018-06`
* Testing with Zoltan's patch
* Include libmono-system-native on Xamarin.Mac
* Bump Mono
Commit list for mono/mono:
* mono/mono@7bcda192a0 Bump llvm to release_60/fc854b8ec5873d294b80afa3e6cf6a88c5c48886. (#9786). (#9804)
* mono/mono@23e95ec7ad Apply F# portable pdb debug fix for pinvokes & bump (#9797)
* mono/mono@295f6d32af [2018-06] [MacOS] On Mac, use the copyfile API to copy files (#9696)
Diff: 7d5f4b6136...7bcda192a0
* Revert 4bacab3d5c, it doesn't fix the ios aot problems.
* Bump mono
* [tests] Adjust the MT0137 test for mcs change in behavior.
Starting with mono 5.16 mcs will now add assembly references when the assembly
is only used in attributes (this was already the case for csc in both 5.14 and
5.16, so it seems to be a compatibility change).
Adjust the MT0137 test accordingly.
* [msbuild] Fix parsing of json parser errors to handle trailing periods in the error message.
Fixes this test:
1) Test Failure : Xamarin.iOS.Tasks.Bug60536.TestACToolTaskCatchesJsonException
ColumnNumber
Expected: 2
But was: 0
* Bump mono
* [builds] Install the old llvm binaries into the LLVM36 directory and make the 32 bit builds use that.
* Bump mono
* Bump mono
* [jenkins] Don't give VSTS a fake branch. (#4667)
Something in VSTS changed, and now fake branch names don't work anymore.
So instead use real branch names (and for pull requests I've created a
'pull-request' branch we can use).
* Assembly.LoadFile accepts only absolute path
* [linker] Add new Facade (System.Threading.Tasks.Extensions).
Fixes these MTouch test failures:
1. Xamarin.Linker.SdkTest.iOS_Unified : Facades
Expected:
But was: < "System.Threading.Tasks.Extensions" >
2. Xamarin.Linker.SdkTest.tvOS : Facades
Expected:
But was: < "System.Threading.Tasks.Extensions" >
3. Xamarin.Linker.SdkTest.watchOS : Facades
Expected:
But was: < "System.Threading.Tasks.Extensions" >
* [mono-sdks] Necessary changes to unify the LLVM provisioning for both iOS and Android. (#4732)
* Bump Mono
* [mtouch] add mixed-mode support (#4751)
* [mtouch] add --interp-mixed option
When enabling this option, mtouch will AOT compile `mscorlib.dll`. At
runtime that means every method that wasn't AOT'd will be executed by
the runtime interpreter.
* [mtouch] Add support to --interpreter to list the assemblies to (not) interpret.
* [msbuild] Simplify interpreter code to use a single variable.
* Fix whitespace.
* [mtouch] Move mtouch-specific code to mtouch-specific file.
* [msbuild] An empty string is a valid value for 'Interpreter', so make it a non-required property.
* [mtouch] Add sanity check for aot-compiling interpreted assemblies.
* Bump Mono
* [linker] Updates SDKs facades list
* Bump mono
* [msbuild] Adds facades which might override default nuget version to framework list
The collision resolver task reads them from here https://github.com/dotnet/sdk/blob/master/src/Tasks/Common/ConflictResolution/FrameworkListReader.cs
* Bump to a VSfM version that can build XM Classic projects.
* [AppKit] Fix issue 4837 by moving the category to be inline. Fixes#4837
The NSControlEditingSupport needs to be inline to make the use of the
API simpler allowing users to inherit an override the method.
Fixes https://github.com/xamarin/xamarin-macios/issues/4837
Fixes these warnings:
build/mac/mobile/Foundation/NSUrl.g.cs(41,30): warning CS0660: 'NSUrl' defines operator == or operator != but does not override Object.Equals(object o)
build/mac/mobile/Foundation/NSUrl.g.cs(41,30): warning CS0661: 'NSUrl' defines operator == or operator != but does not override Object.GetHashCode()
build/mac/full/Foundation/NSUrl.g.cs(41,30): warning CS0660: 'NSUrl' defines operator == or operator != but does not override Object.Equals(object o)
build/mac/full/Foundation/NSUrl.g.cs(41,30): warning CS0661: 'NSUrl' defines operator == or operator != but does not override Object.GetHashCode()
build/mac/full/Foundation/NSUrl.g.cs(41,30): warning CS0660: 'NSUrl' defines operator == or operator != but does not override Object.Equals(object o)
build/mac/full/Foundation/NSUrl.g.cs(41,30): warning CS0661: 'NSUrl' defines operator == or operator != but does not override Object.GetHashCode()
build/mac/mobile/Foundation/NSUrl.g.cs(41,30): warning CS0660: 'NSUrl' defines operator == or operator != but does not override Object.Equals(object o)
build/mac/mobile/Foundation/NSUrl.g.cs(41,30): warning CS0661: 'NSUrl' defines operator == or operator != but does not override Object.GetHashCode()
We've already ignored these warnings in NSUrl.cs [1], but since NSUrl is a
partial class, and the warning applies to the class, it seems the order the
source files are passed to csc determines whether csc reports the warning or
not.
[1] 1f5ba0b5c0/src/Foundation/NSUrl.cs (L30-L31)
* The dispatch_get_main_queue function doesn't exist anywhere (tested on iOS 5.1.1 - iOS 12, macOS 10.7 - 10.14), and when called from native code, it's always an inlined function, so just remove the call completely.
* Getting the _dispatch_main_q symbol from either the current address space, libSystem or libdispatch works fine everywhere. Looking up something in the current address space is costly (according to 'man dlsym'), so stop doing that: only look in libdispatch (since that's where the symbol actually is according to 'nm').
* I find no reason for the lock in DispatchQueue.MainQueue, nor does history reveal anything helpful, so I removed the lock.
* [CoreFoundation] Fetch a few static values lazily.
This avoids using static constructors, and also avoids fetching the values
unless they're needed.
* Generate the code for _dispatch_data_destructor_free instead of using a manual binding.
* [CoreFoundation] Bind kCFBooleanTrue/kCFBooleanFalse using the generator.
Since the generator doesn't know about CFBoolean, bind as IntPtr instead, and
fix most callers to use the handle directly, instead of getting a CFBoolean
object and then immediately getting the handle.
* Add back comment.
* Update xtro.
* Fix typo check.
* Use complete path for the library in the Field attribute.
* Update xtro.
Fix numerous issues with NSLayoutManager[Delegate]:
* The classes are available in both AppKit and UIKit, but the bindings are
duplicated (unsuccessfully) in both appkit.cs and uikit.cs. So create a new
xkit.cs that is shared between XI and XM, and put a shared version of the
bindings there.
* Bind everything that hasn't already been bound (or deprecated by Apple).
* Methods that take a nullable NSRangePointer has been bound with three overloads:
* A protected overridable (exported) method that uses IntPtr.
* A public method without the parameter.
* A public method with the parameter typed as 'ref NSRange'.
This makes sure the native method can be overridden if needed, while at
the same time making it possible to call without providing the nullable
parameter.
* Fix numerous ugly bindings:
* There's a great nint/nuint confusion for parameters referring to
'character index' and 'glyph index'. XI seems to prefer nuint, while XM
seems to prefer nint. Standardize on nuint, since that's how Apple
created them.
* Many methods have names than sound like Objective-C. Fix them all,
either right away when possible, or for XAMCORE_4_0.
* Several parameter names have been modified to comply with our naming
guidelines (no abbreviations).
Fixes https://github.com/xamarin/xamarin-macios/issues/4740.
* Fix the `NATIVE_APPLE_CERTIFICATE` logic; it should only be defined when
using `XAMARIN_APPLETLS` and not on watch.
* It is no longer allowed to construct `X509Certificate` from a native pointer,
the `X509Certificate(IntPtr)` and `X509Certificate2(IntPtr)` constructors now
throw an exception. Use `X509CertificateImplAppl` directly instead.
* [CoreMedia] Expose the CMSampleAttachmentKey interface. Fixes#4688
We have an issue when the user wants to use the CMAttachmentSample,
ideally, the user will want to do:
var cameraIntrinsicData = CMAttachmentBearer.GetAttachment(CMSampleAttachmentKey.CameraIntrinsicMatrixKey, sampleBuffer );
Instead of the current workaround:
var att = new CMSampleBufferAttachmentSettings (sampleBuffer.GetAttachments (CMAttachmentMode.ShouldNotPropagate));
var matrix = att.CameraIntrinsicMatrix;
With this push, we can allow the user use the first example provided in
this commit.
Fixes https://github.com/xamarin/xamarin-macios/issues/4688
Once upon a time mtouch was a MonoMac app, and at the same time needed to
be a 64-bit executable. This meant we needed a few hacks to make things work:
* The source code for CoreFoundation was included in mtouch (instead of using them from MonoMac.dll).
* A few changes were required to make the source code work in 64-bit.
These changes were conditionally done with a #if MTOUCH.
mtouch stopped being a MonoMac app a long time ago, so these mtouch-specific
changes are no longer needed, so just remove them.
The structs MTLQuadTessellationFactorsHalf and
MTLTriangleTessellationFactorsHalf are wrong as per the header
definition:
```c
typedef struct {
/* NOTE: edgeTessellationFactor and insideTessellationFactor are interpreted as half (16-bit floats) */
uint16_t edgeTessellationFactor[4];
uint16_t insideTessellationFactor[2];
} MTLQuadTessellationFactorsHalf;
typedef struct {
/* NOTE: edgeTessellationFactor and insideTessellationFactor are interpreted as half (16-bit floats) */
uint16_t edgeTessellationFactor[3];
uint16_t insideTessellationFactor;
} MTLTriangleTessellationFactorsHalf;
```
We set the arrays size to be the correct one.
Fixes https://github.com/xamarin/xamarin-macios/issues/4611
* Add tests that ensure that the size of the managed structs is the same
as the native ones.
The values used have been checked against a native app compiled on 32
and 64 (iphone 5 and iphone X).
Swift-o-matic needs it, see https://github.com/xamarin/maccore/pull/1049/files#diff-eeaff638ac8b77c777e1bde26cdf6a40R1938.
Also remove a FIXME/unneeded comment. The existing Runtime.GetINativeObject
(..., Type) existed because it's hard to call a generic function from native
code, but if one day that could be figured out, then this managed function
could be removed.
Now that the function is public, we can't remove it even if we figure out how
to call the generic version from native code, so the FIXME is no longer needed.
We don't need to use a custom mono to run the generator anymore, so stop doing
it.
Unfortunately we can't remove the custom mono, since we're now using it for
another purpose (AOT-compiling XM apps).
Fixes https://github.com/xamarin/xamarin-macios/issues/3675.
* Avoid `ArgumentNullException` in default/empty `SecProtocolMetadata.PeerPublicKey`
* Add two `SecProtocolMetadata.CreateSecret` API - disabled as the current tests (incomplete?) crash in unit tests
* Add basic unit tests for `[Sec|NW]ProtocolMetadata`
* Update xtro
This means less (duplicated) manual code, which means less errors, which also
means we're now getting some new members that previously weren't duplicated
correctly.
Fixes https://github.com/xamarin/xamarin-macios/issues/4183.
* Move `NLTag` to static class (instead of enum) since it's not used in API, except along NSString. Fixes https://github.com/xamarin/xamarin-macios/issues/4774
* Add new member to `NLLanguage` to avoid `ArgumentNullException` when it has not been evaludated (API returns `null`), see unit tests;
* Add `[Params]` to `NLTagger` constructors so they are easier to use (no need to create the array in source);
* Fix `GetTag` so it returns (`out`) the `NSRange`, it's natively a `NSRangePointer`;
* Fix `GetTag[s]` API with changes to `NLTag` de-enumification;
* Add unit tests
`CreateIndirectRenderCommand` implies we're creating the command while this API "returns the CPU-based indirect render command at the given index of the indirect command buffer". Moving to `GetCommand` which is more accurate.
* Add support for delegates as return values in protocol members. Fixes#4102.
This required a few changes:
* The generator now emits the DelegateProxy attribute for property getters in
protocol interfaces.
* The generator now emits the DelegateProxy attribute in ProtocolMember
attributes (and the ProtocolMember attribute has been extended with
additional properties for this purpose).
* The generator now emits the BlockProxy attribute for the parameter in
property setters.
* The generator now emits the BlockProxy attribute in ProtocolMember
attributes for property setters.
* The static registrar now emits the metadata token for the
DelegateProxy.DelegateType property into the generated code so that the
DelegateProxy attribute itself isn't needed at runtime. This is required
when the dynamic registrar has been optimized away.
Fixes https://github.com/xamarin/xamarin-macios/issues/4102.
* [tests] Update MX4105 test to expect new warnings.
* [src] Strip reference assemblies now that the generator doesn't need them anymore.
* [src] Xamarin.TVOS.dll is a 64-bit library, so put it in the correct directory.
This way mtouch will find the non-reference assembly.
* [Security] Add missing SecProtocolMetadata missing API.
This is a partial commit that contains most of the missing methods for
the handlers API on SecProtocolMetadata. The not added ones are more
complicated and will be added in a later commit.
The generator already generate the `Handle` code *when* there are fields,
which we now have (recent commit) so the manual code is no longer needed.
Added availability attributes to enums to help documentation generation.
- Fixes#4441: [generator] Binding with return value of Class [] do not do the right thing
(https://github.com/xamarin/xamarin-macios/issues/4441)
- Turns out the logic to put INativeObjects into NSArrays was already in place. We simply needed to add the missing (IntPtr handle, bool owns) overload to `Class`.
- Uncommented AppKit `registeredImageRepClasses` since it was using `Class []`. Tested locally and it works fine.
- Reimplemented `Foundation`'s `NSSecureUnarchiveFromDataTransformer` and its test which were also using `Class []`.
* [src] Fix bgen build to support custom output directory for api comparison. Fixes maccore#959.
This broke in 87c27e0c3f, which made bgen
compile using a project file (I forgot to verify that it wouldn't affect the
API comparison, and the PR build didn't complain because problems with the API
comparison typically show up in subsequent PRs).
https://github.com/xamarin/maccore/issues/959
* [src] Fix response file usage to use BUILD_DIR, so that API comparison can redirect as expected.
* [src] Fix generation of generator.csproj's dependency file to use BUILD_DIR, so that API comparison can redirect as expected.
* [src] Fix bgen.exe's dependencies.
* Use full paths to create-makefile-fragment.sh.
- Fixes#4694: NSString.GetLocalizedUserNotificationString not working with .stringsdict files
(https://github.com/xamarin/xamarin-macios/issues/4694)
- Updated `UNNotificationCategory.FromIdentifier`'s iOS 12 overload to take a `NSString` category format to preserve localization.
- Change `GetLocalizedUserNotificationString` to only use NSString to preserve localization (similar fix to https://github.com/xamarin/xamarin-macios/pull/3266).