* [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.
* [xharness] Improve logging a bit.
* Use timestamp in more log paths.
* Create numbered log subdirectories to make things nicer to look at in a
terminal (thousands of subdirectories can be annoying to shift through; this
way there's an additional subdirectory level).
* Avoid string interpolation when not needed.
* [msbuild] Implement support for faking the watchOS 4.3 SDK. Fixes#4810.
The App Store requires the arm64_32 architecture when building with Xcode 10.
Unfortunately we don't support arm64_32 quite yet, so we need to make the App
Store think watch extensions were built with Xcode 9.4 in order to pass
validation.
Fixes https://github.com/xamarin/xamarin-macios/issues/4810.
* [msbuild] Remove debug spew.
Sometimes files just shrink, and we must cope.
Two possible causes I can think of:
* System log rotation.
* We erase a simulator when trying to capture its system log.
There are probably many more causes, but two is more than enough to make sure
we don't fail when it happens.
* [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.
This means we'll get an empty diff if there are no generator changes, so
update the logic that detects/reports empty generator diffs.
Also there's no need to ignore mdbs anymore, since we don't create mdbs.
It seems older iOS versions have a bug where big(ish) chunks of string can
cause it to hang.
Fix this by not writing big strings to NSLog, instead split them up in chunks.
Fixes https://github.com/xamarin/maccore/issues/1014.
* [builds] Adjust ifdefs to fix not building device architectures. Fixes maccore#1074.
Fixes https://github.com/xamarin/maccore/issues/1074.
* [jenkins] Running configure and then cleaning everything is kind of useless, so reverse the order.
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.
This solves two problems:
* xharness thinks it crashed if the exit code is neither 0 nor 1, and
helpfully says so and tries to collect crash reports, which only ends up
being confusing.
* The exit code is byte-sized on macOS. This means that trying to return 256
actually returns 0 (success).
* [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
* [msbuild] Fix SceneKit asset compilation. Fixes#3766.
It seems SceneKit assets must be compiled into a directory whose parent
directory is named like the app.
In addition the `--resource-folder-path` argument is required.
Fixes https://github.com/xamarin/xamarin-macios/issues/3766.
* [msbuild] Use AppBundlePath to get correct .app[ex] variant.
* [msbuild] Fix XM builds.
* [msbuild] Use AppBundleDir instead of AppBundlePath.
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).
* XI references updated from `xcode10` (XI 12.0)
* XM references are not updated, we continue to compare with `d15.8`
* references_/* were temporary files that should not have been committed (old mistake)
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.
Manuel de la Pena
Rolf Bjarne Kvinge
Xamarin Jenkins User
Chris Hamons
Sebastien Pouliot
Connor Adsit
Matt Sylvia
Vincent Dondain
Michał Żołnieruk