These were accidentally not disabled when we started running tests on Wrench
like we do on Jenkins.
So disable them, to avoid duplicate work on Wrench.
We already have the information we need to generate these function
declaration, so this prevents the need for keeping information in two
different places up-to-date.
Caching the result of checking whether a type is a CIFilter or not in a
dictionary makes the total time spent in the method go down to approximately a
third (11ms to 3ms) when linking monotouch-test on my machine.
and ensure the temporary `NSString` instance is disposed asap.
Found will debugging something else. Unit tests added to confirm there
is no behavior change when the API are used.
Previous behavior
=================
* The linker would determine if a class is a generated binding class or not.
This was determined by the presence of a constructor taking a single IntPtr
argument, and with a [CompilerGenerated] attribute.
* If a class was not a generated binding class, then that class and all its
superclasses were marked as not optimizable (in the context of inlining the
IsDirectBinding check).
* The end result was that all classes with a [CompilerGenerated] IntPtr
constructor that weren't subclassed, were optimized (the IsDirectBinding
value was implied to be 'true').
Unfortunately this does not match how the IsDirectBinding value is actually
computed, and is in many cases quite wrong.
Background
==========
The authorative value for the IsDirectBinding value is the register attribute:
```csharp
[Register ("MyClass", true)] // the second parameter specifies the IsDirectBinding value
class MyClass : NSObject {}
```
Due to history this second parameter is called `IsWrapper` and not
`IsDirectBinding`, but it's the exact same thing.
Unfortunately looking up this attribute every time a class is instantiated is
slow (since fetching attributes is slow), so we guess this value in NSObject's
initialization: if the actual type of the object is in the platform assembly,
then we assume IsDirectBinding=true:
```csharp
IsDirectBinding = (this.GetType ().Assembly == PlatformAssembly);
```
and any subclasses in the platform assembly which is not a direct binding have
to set the correct value in their constructors.
New behavior
============
In the linker we now track three states for the IsDirectBinding value for each
class: if it can be inlined into a constant true or false, or if it has to be
checked at runtime (a nullable bool is used, and null corresponds with this
last undetermined state).
* The linker will look at the `[Register]` attribute for a class, and:
* If the type is CIFilter, store that IsDirectBinding=undetermined.
* If IsWrapper=False, store that IsDirectBinding=False for that class, and
that IsDirectBinding=undetermined for all super classes where
IsWrapper=True.
* If IsWrapper=True, tentatively assume IsDirectBinding=True in that class
unless already determined to be undetermined (which will be overruled if
a non-wrapper subclass is found later).
Results
=======
For monotouch-test, the changes are as follows:
* Classes we can now assume IsDirectBinding=true: https://gist.github.com/rolfbjarne/acd6a8cf1236562a832d6db9400afee9#file-foo-diff-L1-L25
* Classes we previously assumed incorrectly that IsDirectBinding=true: https://gist.github.com/rolfbjarne/acd6a8cf1236562a832d6db9400afee9#file-foo-diff-L27-L645
* Classes we can now assume IsDirectBinding=false: https://gist.github.com/rolfbjarne/acd6a8cf1236562a832d6db9400afee9#file-foo-diff-L647-L2281
There are also minor size improvements (in the iPhone/Debug64 configuration):
The executable is 17.632 bytes smaller:
-rwxr-xr-x 1 rolf staff 73038384 Jan 12 12:40 /Users/rolf/test/old/monotouchtest.app/monotouchtest
-rwxr-xr-x 1 rolf staff 73020752 Jan 12 12:50 /Users/rolf/test/new/monotouchtest.app/monotouchtest
Xamarin.iOS.dll is 3.072 bytes smaller (this will probably be 0 on a release (stripped) build).
-rw-r--r-- 1 rolf staff 2522624 Jan 12 12:40 /Users/rolf/test/old/monotouchtest.app/Xamarin.iOS.dll
-rw-r--r-- 1 rolf staff 2519552 Jan 12 12:50 /Users/rolf/test/new/monotouchtest.app/Xamarin.iOS.dll
CIFilter
========
There's a complication with CIFilters [1] [2], their implementation is
somewhat special, so we do not want to optimize anything for those classes to
not risk getting anything wrong.
[1] https://github.com/xamarin/xamarin-macios/pull/3055
[2] https://bugzilla.xamarin.com/show_bug.cgi?id=15465
* [mtouch][mmp] Report invalid debug symbols files. Fixes#3200
Try to read the assembly with symbols and, if that fails, warn and
fallback to loading them without symbols.
This fixes cases were it's not easy to update or delete (e.g. nuget)
bad symbols files - so this cannot be an error without causing a lot
of pain.
However it needs to be reported, otherwise it wont be fixed (by the
publisher) and it can limit the debugability of the application and
the usefulness of the stacktraces.
Finally merge most of the resolver's code between mtouch and mmp so
we don't have to fix such issue twice anymore.
note: this needs to be slightly updated once we get a version of cecil
that can give us a more precise error message.
Also bring Rolf's tests from
https://github.com/xamarin/xamarin-macios/pull/3079
reference:
https://github.com/xamarin/xamarin-macios/issues/3200
* [msbuild] DetectSigningIdentity fix for Mac when RequireProvisioningProfile is false
Fixes https://github.com/xamarin/maccore/issues/612
* Disable some tests since they don't make correct assumptions anymore
* Added comment to explain why tests are disabled
This now formal `CAAnimationDelegate` protocol had to be reverted [1]
because we did not support `FormalSince` at the time - and this broke the
static registrar when used with older SDK. Support was added in [2] but
did not include `CAAnimationDelegate` (but `CALayerDelegate` was fixed).
Because this was not a protocol the `Delegate` property expose it as a
`CAAnimationDelegate`, the concrete/model type, and not an interface.
The workaround so `ICAAnimationDelegate` can be used, thru the
`WeakDelegate`, requires to manually re-bind some API because the
generator won't allow this anymore (it's bad to expose a [Model]
when a [Protocol] exists).
xtro data updated
[1] https://github.com/xamarin/xamarin-macios/pull/698
[2] https://github.com/xamarin/xamarin-macios/pull/2130
In particular the mmp tests build a lot of project files, which means they can
find issues whenever something in the MSBuild logic changes, so run them.
They would have caught https://github.com/xamarin/maccore/issues/612 for instance.
Fixesxamarin/xamarin-macios#3166
Apple broke `addAnimation:forKey:` API by changing `CAAnimation` parameter into a
`ISCNAnimationProtocol` that was introduced in Xcode 9 (iOS 11 and company).
We can't break the existing API but we can add an extension method that
reuses the `CAAnimation` overload but takes a `SCNAnimation` and we
turn the `SCNAnimation` into a `CAAnimation` behind the scenes.
For XAMCORE_4_0 we corrected the protocol signature to take `ISCNAnimationProtocol` so there won't be a need for the extension method anymore.
* [linker] Refactor and simplify code optimizations.
We had several types of code optimizations, where we'd determine a particular
expression is a constant, then remove the condition and the code for any
dead branches.
Unfortunately each type of expression had its own logic to determine the
sequence of code to remove, each slightly different depending on the actual
conditional expression. This has led to bugs in the past, either when
switching between compilers (mcs/csc), or compilers have changed their emitted
code.
So implement a more generic version where each optimization just changes the
specific condition to a constant value, and then at the end we have a dead-
code-elimination pass that eliminates dead code based on those constant
conditions.
This version is also a lot more defensive than the previous code, it will bail
out without doing anything if it finds a code sequence it doesn't understand.
This also makes it easier to implement other similar code optimizations.
Simple time measuring shows no slowdown in the linker, and the size difference for monotouch-test is negligable at best:
256 bytes more for the exectuable:
-rwxr-xr-x 1 rolf staff 72890464 Dec 1 14:39 /Users/rolf/test/old/monotouchtest.app/monotouchtest
-rwxr-xr-x 1 rolf staff 72890720 Dec 1 14:44 /Users/rolf/test/new/monotouchtest.app/monotouchtest
3584 bytes less for Xamarin.iOS.dll:
-rw-r--r-- 1 rolf staff 2506240 Dec 1 14:39 /Users/rolf/test/old/monotouchtest.app/Xamarin.iOS.dll
-rw-r--r-- 1 rolf staff 2502656 Dec 1 14:44 /Users/rolf/test/new/monotouchtest.app/Xamarin.iOS.dll
I don't know why the executable grew slightly, the IL diff for Xamarin.iOS.dll
shows nothing out of the ordinary:
https://gist.github.com/rolfbjarne/33590ad651a21f9a9352ac9b97b9dc06
* [linker] NewRefcount is constantly true for Unified, so trying to inline it is useless.
* [linker] Remove redundant code.
* [linker] Remove nops at the end of methods.
It's not legal IL to have a nop as the last instruction of a method, peverify complains:
> [IL]: Error: [D:\Documentos\Rolf\Xamarin\Xamarin.iOS.dll : AVFoundation.AVAssetImageGenerator::get_AppliesPreferredTrackTransform][offset 0x0000001E] fall through end of the method without returning
so detect and remove nops at the end of methods.
Also add a sanity check to ensure we don't remove nops that are targets for
branch instructions (should never happen, but it doesn't hurt to be safe).
PEVerify shows much fewer errors now, [1721][1] vs [2581][2], although the [IL diff][3]
is bigger (due to the removed nops).
Updated timing measurements show no slowdown in the linker, and the size
difference for monotouch-test is negligable:
32 bytes less for the exectuable:
-rwxr-xr-x 1 rolf staff 72890880 Jan 12 00:54:49 2018 /Users/rolf/test/old/monotouchtest.app/monotouchtest*
-rwxr-xr-x 1 rolf staff 72890848 Jan 12 00:56:57 2018 /Users/rolf/test/new/monotouchtest.app/monotouchtest*
12288 bytes less for Xamarin.iOS.dll (this is a debug build, a release build
would probably not show any difference at all):
-rw-r--r-- 1 rolf staff 2506240 Jan 12 00:54:49 2018 /Users/rolf/test/old/monotouchtest.app/Xamarin.iOS.dll
-rw-r--r-- 1 rolf staff 2493952 Jan 12 00:56:57 2018 /Users/rolf/test/new/monotouchtest.app/Xamarin.iOS.dll
[1]: https://gist.github.com/rolfbjarne/9c8fa519a6f8e1718b125472f05ded07#file-peverify-new-txt-L1726
[2]: https://gist.github.com/rolfbjarne/9c8fa519a6f8e1718b125472f05ded07#file-peverify-old-txt-L2586
[3]: https://gist.github.com/rolfbjarne/35d5bfec1809ad2a80a7781cebe5b574
Largely related to somewhat recent frameworks/API additions to XM
ExternalAccessory was added to macOS 10.13 (Xcode9) and can't be run before that (including on the jenkins sierra bots). Also enable that test on tvOS (which added support in Xcode8)
Sadly this creates a breaking change since the `ScaleTransform`
property was re-introduced with an incorrect signature in the new
base class `MPSImageScale`
Unless someone has an idea how to avoid it (I don't see an option)
then we'll have to document it in the 15.7 release notes.
Also add missing _SetScaleTransform call and related unit tests
For some strange reason the following sometimes work with make v3.8.1:
X/:
mkdir X
X/Y: X
mkdir X/Y
Note how the second target specifies `X` as a dependency, but the actual
target to be executed is `X/` (additional trailing slash).
It does not work with remake (v4.2.1), nor in a simple test case like the one
above with make (v3.8.1), but it works in our own makefiles (which are
admittedly slightly more complicated).
Since it's trivial to fix, and I don't understand how it works in make in the
first place, I'm just changing it to what makes sense (and works everywhere):
remove trailing slashes from all directories that are used as targets.
Don't *always* codesign, especially for iOS8 which seems to break.
iOS Simulator builds should only be codesigned if they require
Entitlements (signified by RequireProvisionProfile).
This fixes xamarin-macios#3145 and xamarin/xamarin-macios#3146
This workarounds an Apple breaking change (since `SCNAnimation` protocol is new in iOS 11):
The Old definition was
> typedef void (^SCNAnimationEventBlock)(CAAnimation animation, id _Nonnull animatedObject, BOOL playingBackward)
The new ObjC definition is:
> typedef void (^SCNAnimationEventBlock)(id<SCNAnimation> animation, id animatedObject, BOOL playingBackward);
and it is bound as:
> delegate void SCNAnimationEventHandler (CAAnimation animation, NSObject animatedObject, bool playingBackward);
and for watchOS and XAMCORE_4_0 it is bound as:
> delegate void SCNAnimationEventHandler (ISCNAnimationProtocol animation, NSObject animatedObject, bool playingBackward);
Fortunatelly `CAAnimation` conforms to `SCNAnimation` protocol and
we are now abusing this fact and forcing its creation with `GetINativeObject`
this way we keep a single API and we can always completely fix this
when XAMCORE_4_0 happens following suit with apple's breaking change.
Fixesxamarin/xamarin-macios#3140
According to headers and documentation this should not be abstract.
This was incorrectly added by me in 89071bc19d
I could not find why this was added by checking headers nor I can
recall why I added it so I'll just say it was a honest mistake :) Oops... 🙈
Previous PMCS removal changes froze XamMac.BindingAttributes.dll but not bgen.exe which causes interesting issues when we make changes there and run classic XM tests.
This can be seen here: #3147
This PR freezes bgen-classic in macios-binaries (which will need to be added to master and bumped before this goes in) and update various scripts/tests.
Before XAMCORE_4_0 the setter will throw an `NotImplementedException`
which is better, and more accurate, than a native exception.
Found by xtro. Data file updated.
We normally frown on large scale _cosmetic_ changes, mostly because it breaks git's history (very useful) and makes merging branches harder and more error prone (very annoying).
However we require, right now, such changes to remove our old, mcs-based, pre-processor (pmcs) so it's a _good_ time to address the old, unneeded availability attributes - since most of them are re-written for our next milestone.
This won't change the final application size in most cases, as the linker removes them, but it will make the (unlinked) platform assemblies smaller. This means they will load faster (e.g. by mtouch, mmp, IDE, workbooks...) and will reduce the time/memory needed to reflect them.
* SLComposeServiceViewController has [Mac] specific stuff but was
excluded under a (too large) `#if !MONOMAC`
* SLComposeSheetConfigurationItem::init is a designated initializer
* SLRequest::addMultipartData:withName:type: is macOS-only and missing
xtro results:
!missing-designated-initializer! SLComposeSheetConfigurationItem::init is missing an [DesignatedInitializer] attribute
!missing-selector! SLComposeServiceViewController::charactersRemaining not bound
!missing-selector! SLComposeServiceViewController::contentText not bound
!missing-selector! SLComposeServiceViewController::placeholder not bound
!missing-selector! SLComposeServiceViewController::setCharactersRemaining: not bound
!missing-selector! SLComposeServiceViewController::setPlaceholder: not bound
!missing-selector! SLComposeServiceViewController::textView not bound
!missing-selector! SLRequest::addMultipartData:withName:type: not bound
!missing-type! SLComposeServiceViewController not bound
* PHLivePhotoView only available on 64 bits
xtro results:
!missing-enum! PHLivePhotoViewContentMode not bound
!missing-enum! PHLivePhotoViewPlaybackStyle not bound
!missing-protocol! PHLivePhotoViewDelegate not bound
!missing-selector! PHLivePhotoView::audioVolume not bound
!missing-selector! PHLivePhotoView::contentMode not bound
!missing-selector! PHLivePhotoView::delegate not bound
!missing-selector! PHLivePhotoView::isMuted not bound
!missing-selector! PHLivePhotoView::livePhoto not bound
!missing-selector! PHLivePhotoView::livePhotoBadgeView not bound
!missing-selector! PHLivePhotoView::setAudioVolume: not bound
!missing-selector! PHLivePhotoView::setContentMode: not bound
!missing-selector! PHLivePhotoView::setDelegate: not bound
!missing-selector! PHLivePhotoView::setLivePhoto: not bound
!missing-selector! PHLivePhotoView::setMuted: not bound
!missing-selector! PHLivePhotoView::startPlaybackWithStyle: not bound
!missing-selector! PHLivePhotoView::stopPlaybackAnimated: not bound
!missing-type! PHLivePhotoView not bound
* [xtro] Sort earlier in EnumCheck so we don't have to duplicate checks (or get random failures)
Setting `NSMenuItem.Activated` internally creates the `ActionDispatcher` object that is assigned to the `Target` property.
When the menu item gets activated the system calls `NSApplication.SendAction`, which internally
checks the `WorksWhenModal` property on the `Target` object before proceeding with the action.
Since `ActionDispatcher` is not part of the normal `NSResponder` chain it needs to implement the property itself to ensure the event is fired even when the menu is opened from a modal window.
That fix a NRE while running xtro
12:55:31.4682580 System.NullReferenceException: Object reference not set to an instance of an object
12:55:31.4682960 at Extrospection.Helpers.GetFramework (Mono.Cecil.TypeReference type) [0x00012] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xtro-sharpie/Helpers.cs:284
12:55:31.4683110 at Extrospection.EnumCheck.VisitManagedType (Mono.Cecil.TypeDefinition type) [0x0006c] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xtro-sharpie/EnumCheck.cs:28
12:55:31.4683210 at Extrospection.AssemblyReader.ProcessType (Extrospection.BaseVisitor v, Mono.Cecil.TypeDefinition type) [0x00001] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xtro-sharpie/Runner.cs:78
12:55:31.4683320 at Extrospection.AssemblyReader.Load (System.String filename) [0x00079] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xtro-sharpie/Runner.cs:71
12:55:31.4684210 at Extrospection.Runner.Execute (System.String pchFile, System.Collections.Generic.IEnumerable`1[T] assemblyNames) [0x000f2] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xtro-sharpie/Runner.cs:41
12:55:31.4684400 at Extrospection.MainClass.Main (System.String[] args) [0x00046] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xtro-sharpie/Program.cs:20
https://jenkins.mono-project.com/job/xamarin-macios-pr-builder/5845/Test_Report/
Short story: PR #3096 adds **non public** attributes without a namespace
so they take precedence over existing ones.
xtro enum check also needed to discard them.
- XamarinPreprocessorVisitor handled processing/generating availability
attributes but needs to be removed as it depends on PMCS
- Because processing was handled at a preprocessor/token level before and
now inside generator.cs a number of changes were needed avoid checking
in a million line diff (literally)
- This commit creates a "shadow" set of availability attributes, with
the desired names [Mac] [Watch] [NoTV], etc when not in existence before
- Instead of adding hundreds of using statements to force resolution of these
shadow types, I abuse C# type resolution by storing them in the root
(not namespaced) so they are resolved first.
- generator-attributes-manager was taught how to process the multitude of
old-style attributes and how to generate the new-style attributes
- Generator's bug57070 is no longer valid, since we _can_ and do convert [iOS]
- Remove PMCS injection of command line arguments. Handled directly by Makefile
- Classic iOS is still building for now due to documentation issues but will be removed at a later date.
We can't trust Apple's native linker to pick the right (non private)
framework when an older TargetVersion is used. It just prefer what's
available - even if specified with a WeakFramework :(
That was already dealt with for applications. However the native linking
of the Xamarin.Sdk.framework (code sharing with extensions) is done with
the `LinkTask` instead of the `NativeLinkTask` so it did not have the
"auto correct" code.
Unit test added.
reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=61039
Sebastien Pouliot
Manuel de la Pena
Rolf Bjarne Kvinge
Jeffrey Stedfast
Alex Soto
Vincent Dondain
Timothy Risi
Chris Hamons