The original, now obsoleted, `LocalizedString` API returned a .net
`string` which does not work in most cases.
Different versions of iOS seems to return different (public or internal)
subclasses of `NSString` that are understood by other API (like NSString
`localizedStringWithFormat:`) for further customization.
Our logic to convert NSString to string is correct but it cannot
recreate the custom, required subclass to continue the localization.
So the new API return an `NSString` publicly (which is actually a
subclass) that can do the required job.
Adding a test in monotouch-test is presently blocked by #3265 [2]
[1] https://bugzilla.xamarin.com/show_bug.cgi?id=41292
[2] https://github.com/xamarin/xamarin-macios/issues/3265
* Add tests for new (and old) NSBundle API and adjust old ones since adding a Base.lproj directories changes things
* Add localization to xammac_tests since it shares the same, updated tests
When determining the color for a collection of tests, first check if the
execution result is identical for all tests in the collection, in which case
just use the corresponding color for a single test.
Instead of hard-coding the platform as iOS for the EmbedMobileProvision
task, use the SdkPlatform to determine the appropriate platform to use
in the MobileProvisionIndex query.
This is a follow-up fix with near identical changes to the
CompileEntitlements fix for tvOS.
- Fixes bug #59272: [xtro] Report !missing-protocol-conformance! when protocols are defined in categories
(https://bugzilla.xamarin.com/show_bug.cgi?id=59272)
- Implemented missing protocol conformances based on tool's new data.
- Remove Internal check from VisitObjCCategoryDecl and VisitObjCInterfaceDecl
- Ignore previewItemTitle failure (normal since it's optional)
- Only skip UIStateRestoring for subclasses of UIViewController
- Ignore UIStateRestoring test on watchOS (UIViewController not available)
- Remove protocol conformances that generated wrong availability attributes (https://github.com/xamarin/xamarin-macios/issues/3213)
- Avoid new virtual or virtual when adding protocol conformance (https://github.com/xamarin/xamarin-macios/issues/3217)
xharness needs a solution in order to ask for a nuget restore, so make sure to
provide the path to the solution.
This fixes a build issue where the install source tests would fail to build
due to picking up the system's nunit.framework.dll because the nuget one
wasn't found/restored:
MonoPathManglerTest.cs(8,3): error CS0619: 'TestFixtureAttribute' is obsolete: 'The NUnit framework shipped with Mono is deprecated and will be removed in a future release. It was based on NUnit 2.4 which is long outdated. Please move to the NUnit NuGet package or some other form of acquiring NUnit.'
XamarinSourcesPathManglerTest.cs(8,3): error CS0619: 'TestFixtureAttribute' is obsolete: 'The NUnit framework shipped with Mono is deprecated and will be removed in a future release. It was based on NUnit 2.4 which is long outdated. Please move to the NUnit NuGet package or some other form of acquiring NUnit.'
OpenTKManglerTest.cs(8,3): error CS0619: 'TestFixtureAttribute' is obsolete: 'The NUnit framework shipped with Mono is deprecated and will be removed in a future release. It was based on NUnit 2.4 which is long outdated. Please move to the NUnit NuGet package or some other form of acquiring NUnit.'
PathManclerFactoryTests.cs(8,3): error CS0619: 'TestFixtureAttribute' is obsolete: 'The NUnit framework shipped with Mono is deprecated and will be removed in a future release. It was based on NUnit 2.4 which is long outdated. Please move to the NUnit NuGet package or some other form of acquiring NUnit.'
OpenTKManglerTest.cs(29,4): error CS0616: 'TestCase' is not an attribute class
OpenTKManglerTest.cs(30,4): error CS0616: 'TestCase' is not an attribute class
MonoPathManglerTest.cs(29,4): error CS0616: 'TestCase' is not an attribute class
MonoPathManglerTest.cs(30,4): error CS0616: 'TestCase' is not an attribute class
MonoPathManglerTest.cs(31,4): error CS0616: 'TestCase' is not an attribute class
XamarinSourcesPathManglerTest.cs(33,4): error CS0616: 'TestCase' is not an attribute class
XamarinSourcesPathManglerTest.cs(35,4): error CS0616: 'TestCase' is not an attribute class
XamarinSourcesPathManglerTest.cs(37,4): error CS0616: 'TestCase' is not an attribute class
OpenTKManglerTest.cs(36,4): error CS0616: 'TestCase' is not an attribute class
OpenTKManglerTest.cs(37,4): error CS0616: 'TestCase' is not an attribute class
MonoPathManglerTest.cs(37,4): error CS0616: 'TestCase' is not an attribute class
MonoPathManglerTest.cs(38,4): error CS0616: 'TestCase' is not an attribute class
MonoPathManglerTest.cs(39,4): error CS0616: 'TestCase' is not an attribute class
XamarinSourcesPathManglerTest.cs(47,4): error CS0616: 'TestCase' is not an attribute class
These targets will already be properly escaped (using backslash), so adding
quotes will cause make to treat the backslashes literally (and break).
Fixes an issue with package-tests:
$ make package-tests
[...]
build-mac-classic-dont\ link failed
build-mac-unified-dont\ link failed
build-mac-unifiedXM45-dont\ link failed
build-mac-unified32-dont\ link failed
build-mac-unifiedXM4532-dont\ link failed
build-mac-unified-link\ all failed
build-mac-unified-link\ sdk failed
make[4]: *** [build-mac] Error 1
make[3]: *** [mac-test-package.zip] Error 2
make[2]: *** [package-tests] Error 2
* [xharness] Run monotouch-test both with and without the static registrar in the simulator.
This way we catch (some) problems with the static registrar without having to run on device.
* [xharness] Add comments to explain extra test configurations.
* [xharness] Fix how projects are cloned.
Fix how projects are cloned so that xharness doesn't end up confused when
multiple test tasks share the same build task.
Previously xharness would iterate over all test tasks and modifying their
build tasks, now it will create the build tasks correctly in the first place.
https://bugzilla.xamarin.com/show_bug.cgi?id=59294
This enables ImageRepresentation strong dictionary helpers.
--- A note about WrapAttribute
Whenever we use the `WrapAttribute` inside a `Category` we need to
include the `This` parameter as the first argument inside the Wrap
signature, like the following example:
```csharp
[Wrap ("WriteTiffRepresentation (This, image, url, format, colorSpace, options?.Dictionary, out error)")]
bool WriteTiffRepresentation (CIImage image, NSUrl url, CIFormat format, CGColorSpace colorSpace, CIImageRepresentationOptions options, out NSError error);
```
If the assembly is registered in the static registrar, skip it before trying to probe whether it has a reference or not. A dictionary lookup is way faster than probing the referenced assemblies
* [tests] Add 'link all' test for XM.
* [tests] Add 'link sdk' test for XM.
* [tests] Move dontlink-mac tests to linker-mac directory to have the same directory layout as linker-ios.
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.
Sebastien Pouliot
Vincent Dondain
Rolf Bjarne Kvinge
Jeffrey Stedfast
Alex Soto
Marius Ungureanu
Manuel de la Pena
Timothy Risi