Most of these changes are needed from VS to make incremental builds work.
The problem here is VS runs MSBuild on Windows and remotes (most of) the task executions to the Mac. Since MSBuild is running on Windows the inputs and outputs are checked there, but the output files won't be created on Windows unless those are explicitly declared as output ITaskItems of a task. VS don't copy every file created on the Mac back to Windows because that will increase the build time unnecessarily.
For instance, the _GenerateFrameworkDebugSymbols target was using the Info.plist file created by the dsymutil tool as output, but that file was not declared as ITaskItem output of the DsymUtil task so VS didn't know that file should be created on Windows.
This doesn't mean every task should have an output property declaring ITaskItems, but if you're writing a target that will use certain files as output those files should be output of one of the tasks that target is running.
Partial fix for https://dev.azure.com/devdiv/DevDiv/_workitems/edit/710309.
I'm not sure why we have an entry in our list of frameworks claiming that
iTunesLibrary was introduced in macOS 10.9, when we didn't have any bindings
for the library back then.
In any case we also have an entry for iTunesLibrary in our list of frameworks
claiming that iTunesLibrary was introduced in macOS 10.14.
I looked at some of Apple's documentation for the types in iTunesLibrary, and
they all claim to be introduced in macOS 10.13 [2].
And to make matters even more interesting, Apple's documentation for the
framework itself states the library is in
/Library/Frameworks/iTunesLibrary.framework, and ships with iTunes 11.0+ [1]
(which is introduced in 2012).
Then I looked at a macOS 10.14 machine, and the framework is available at
/System/Library/Frameworks/iTunesLibrary.framework, and
/Library/Frameworks/iTunesLibrary.framework is just a symlink there
(/System/Library/Frameworks/iTunesLibrary.framework does not exist on my macOS
10.13 machines, while /Library/Frameworks/iTunesLibrary.framework does). From
this I conclude that the framework was converted into a
system framework in macOS 10.14, and as such our claim that the framework was
introduced in 10.14 is at least somewhat right.
So treat iTunesLibrary as any other framework introduced in macOS 10.14, and
remove our (duplicated) framework entry for 10.9 (for which we didn't have any
bindings anyway).
Also fix the path to the framework, I'm wonder how this got past our tests in
the first place.
[1] https://developer.apple.com/documentation/ituneslibrary: "... located at /Library/Frameworks/iTunesLibrary.framework ... The iTunes Library framework is available to users running iTunes v11.0 or above."
[2] https://developer.apple.com/documentation/ituneslibrary/itlibrary?language=objc
While trying to debug an msbuild unit tests it was not possible to
successfully copy/paste the command from the execution log and
run it in a shell.
It's not that hard to run xharness and figure it out - but the
same can happen on bots (which could be harder).
So that little change prints out the host and xharness changes
to the environment variables to make copy/pasters life even
lazier :)
The task itself should not throw. An invalid argument is an error that
should (and is) reported by `btouch` itself (and the task picks it up).
This makes the error reporting much more useful and the way an exception
is reported, from Windows, is also confusing
```
MessagingRemoteException: An error occured on client Build4110732 while executing a reply for topic xvs/Build/4.11.0.732/execute-task/ClassLibrary1/6e85b94002fBTouch ArgumentNullException: Value cannot be null.
```
Unit tests added.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/656983
* [introspection] MPSCnnBinaryKernel's kernelHeight/kernelWidth are missing on iOS too.
* [introspection] CoreNFC is not even available on all devices.
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.'
When debugging watchOS apps on device, we wait forever [1] for a connection to
be established to the IDE (iOS apps wait for only 2 seconds, but that's
because the app will be killed after a while, which we avoid on watchOS by
attaching the native debugger).
Unfortunately our error handling was not quite optimal, which meant that if
the connection to the IDE failed, we'd wait forever instead of launching the
app without attaching the debugger.
So improve this, by printing "Waiting for connection to the IDE..." messages
while trying to connect, and printing detailed log messages if the
connection attempt fails (as well as terminating the wait and launching the
watch app).
[1] In this case forever technically means "1 hour".
Instead of a generic `MT0000` caused by an exception reading the magic
numbers of the binary framework file.
This was caused be uncompressing an archive, with a symlink, into a
file system that does not support symlinks (on Windows).
ref: https://github.com/xamarin/xamarin-macios/issues/5028
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
Sebastien Pouliot
Rolf Bjarne Kvinge
Sebastien Pouliot
Emanuel Fernandez Dell'Oca
Michiel Sioen
monojenkins
Bernhard Urban
Chris Hamons
Jeffrey Stedfast
Vincent Dondain
Miguel de Icaza