Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge xcode9 into d15-4[-xi] #2710

Merged
merged 365 commits into from
Sep 15, 2017
Merged

Conversation

spouliot
Copy link
Contributor

No description provided.

dalexsoto and others added 30 commits July 20, 2017 10:16
* [FileProvider] Add Xcode 9 Beta 1 Bindings

* Better naming

* Feedback not related to BindAs

* [FileProvider] Removes BindAs, add manual code for it and updated to Beta 3

* [FileProvider] Implement feedback
There's no header change to mention `init` is not allowed but
it's not clear how this default initializer could be used.

Also make public some other API to construct this type (outside
of XM). It's not clear why there were `internal` as they are
(at least now) part of the header files.
…ll (to avoid ambiguous API) (xamarin#2360)

Adding a strongly typed `PHLivePhotoEditingOption` (a strongly typed
version of an `NSDictionary`) can cause a `CS0121` (call is ambiguous)
since using a `null` argument is common (only one option exist so far).

This PR adds overloads that makes the code nicer in such case, e.g.

before Xcode9:

> // null is used when no options are given
> _foo.SaveLivePhoto (output, null, completion);

current (Xcode 9)

> // casting required to remove ambiguity with PHLivePhotoEditingOption
> _foo.SaveLivePhoto (output, (NSDictionary)null, completion);

with this PR

> // no option, no argument
> _foo.SaveLivePhoto (output, completion);

The same applies to `PrepareLivePhotoForPlayback`.
…ates

Those tests were not added to validate xOS so just keep the parts
that helps us (without constantly checking back the new break flavor)
Note: WKWindowFeatures.h is not compiled (part of the framework umbrella)
and the `@interface WKWindowFeatures (WKPrivate)` sounds like it should
not have been exposed (it's all fields starting with `_`)
…s-tests-58348

[tests] Disable watchOS from harness only. Workaround #58348
…arin#2376)

This fix is needed by PDFKit because it is a remapped framework[0],
the current code generates incorrect FieldAttribute on smart enums
because it uses `fa.LibraryName` as first option and this causes
remmaped frameworks have incorrect LibraryName generated for example
if a Field uses `+CoreImage` as `LibraryName` the following incorrect
code is generated:

```
	[Field ("First", "+CoreImage")]
	internal unsafe static IntPtr First {
		get {
			fixed (IntPtr *storage = &values [0])
				return Dlfcn.CachePointer (Libraries.+CoreImage.Handle, "First", storage);
		}
	}
```

[0]: https://github.com/xamarin/xamarin-macios/blob/f5956d6cc1eb5dfa7bab16628cf282d40237f64e/src/generator.cs#L5985
rolfbjarne and others added 22 commits September 13, 2017 18:46
This also requires implementing the corresponding matrix (NMatrix4x3).

Fixes this xtro issue:

> !unknown-simd-type-in-signature! OpenTK.Matrix3 AVFoundation.AVCameraCalibrationData::get_GetIntrinsicMatrix(): the native signature has a simd type (matrix_float3x3), while the corresponding managed method is using an incorrect (non-simd) type.
When checking for category availability, check if both the current declaration
is a category, and if the current's declaration container is a category.

Otherwise this scenario fails:

* Category method is available.
* Category does not have availability attributes.
* Main class is unavailable.

with this typical code sequence:

```csharp
// don't process methods (or types) that are unavailable for the current platform
if (!decl.IsAvailable () || !(decl.DeclContext as Decl).IsAvailable ())
	return;
```

In which case we'd:

* First check the method (`decl`):
	* It's available, so no further checks is done on the method.

* Then we'd check the method's container (`decl.DeclContext`):
	* The container (the category) does not have availability attributes.
	* Then we'd check if the container's container is a category (it isn't, it's the namespace).

and as such determine that the method is available.

With this change, the second step will become:

* Then we'd check the method's container (`decl.DeclContext`):
	* The container (the category) does not have availability attributes.
	* Then we'd check if the container is a category (it is), and if its main class is available (it isn't).

and as such determine that the method is unavailable.

* Check for attributes on the method's container (no attributes, so we continue).
* Check if the method's

Unclassified diff: https://gist.github.com/rolfbjarne/8fa80962596978a426eadf9b7ba39dc1
…arin#2678)

Fixes:

> common.unclassified:!missing-type! AVCapturePhoto not bound

https://bugzilla.xamarin.com/show_bug.cgi?id=59388

* Use strong dictionaries for AVCapturePhoto.Metadata and AVCapturePhoto.EmbeddedThumbnailPhotoFormat.
…amarin#2632)

The following types will be used by ModelIO bindings

* Fix delta to be double

* Rename Simd-compatible matrices and vectors to match our final naming.

This also means removing the new Vector2 and Vector4 variants (but not
Vector3).
…d by the generator (for the availability attributes) (xamarin#2688)
…arin#2690)

* [Intents] Fix watchOS INCarSeatResolutionResult breaking changes

Type Changed: Intents.INCarSeatResolutionResult

Removed methods:

    public static INCarSeatResolutionResult GetConfirmationRequired (INCarSeat valueToConfirm);
    public static INCarSeatResolutionResult GetSuccess (INCarSeat resolvedValue);
…#2691)

!missing-protocol-member! AVCapturePhotoCaptureDelegate::captureOutput:didFinishProcessingPhoto:error: not found

and the selector removed from PR#2687 was actually replaced with this one

!missing-protocol-member! AVAssetDownloadDelegate::URLSession:aggregateAssetDownloadTask:didLoadTimeRange:totalTimeRangesLoaded:timeRangeExpectedToLoad:forMediaSelection: not found
…xamarin#2697)

...even if it is a simulator build.

Turns out that starting with Xcode9, sim builds need to be codesigned
for App Groups entitlements to work properly. Interestingly, the
DetectSigningIdentity logic had a comment about needing to codesign
simulator builds for some entitlements to work already starting with
Xcode 8 but apparently the iOS targets did not respect this.

Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=59379
…in#2693)


https://bugzilla.xamarin.com/show_bug.cgi?id=59247

We need to have a better solution that removes all what NSProxy does not responds to.
Right now this works because NSObject implements NSObject protocol just like NSProxy, but
NSProxy responds to far less selectors hence doing it internal so it is not a breaking change
when we provide the correct fix.

* Keep NSProxy around and avoid XML linker description

We need to keep NSProxy (avoid linking it) if WKNavigationDelegate or IWKNavigationDelegate
is used. We know WKWebView will be there and can hold a reference to it.
…amarin#2706)

Apple rejects apps that links with the previously private IOSurface.framework.
We were not sure about this [1] and had it disabled (this is removed).

However another bug stopped our adjustment logic [2] from being executed. This
is needed since `clang` picks up the private framework if it does not find the
public one (even when asking for a weak framework),

[1] https://bugzilla.xamarin.com/show_bug.cgi?id=59201
[2] Added a while ago for JavascriptCore
Make.config Outdated
XCODE_VERSION=8.3
XCODE_URL=http://xamarin-storage/bot-provisioning/Xcode_8.3.xip
XCODE_DEVELOPER_ROOT=/Applications/Xcode83.app/Contents/Developer
#CODE_VERSION=9
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that intentional?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nope

@monojenkins
Copy link
Collaborator

Build failure

@monojenkins
Copy link
Collaborator

Build success

@spouliot spouliot merged commit 91a53f7 into xamarin:d15-4-xi Sep 15, 2017
@spouliot spouliot deleted the d15-4-xcode9-merge branch September 15, 2017 21:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants