Existing binding binaries won't have the `[Preserve]` attribute on
the `Handler` field and, with the new optimization, would not work
properly.
This tweak make sure that older, already linker-safe, bindings will
remain this way (safe) in this (and future) versions of both iOS and
macOS SDK.
This is caused by a new optimization by the linker which makes it
possible to remove some `.cctor` if it's fields are not preserved.
In earlier versions the linker would actually mark the fields because
of the `.cctor` (whenever a type is used).
While this is the correct fix we'll also need (in progress) to allow
disabling this optimization for existing _linker safe_ code (in part
because other, similar pattern might exists in 3rd party code).
Fix failures such as
```
[FAIL] RegistrarTest.BlockReturnTest : ObjCRuntime.RuntimeException : Invalid DelegateProxyAttribute for the return value for the method MonoTouchFixtures.ObjCRuntime.RegistrarTest+BlockReturnTestClass.MethodReturningBlock: DelegateType (ObjCRuntime.Trampolines+SDRegistrarTestBlock) specifies a type without a 'Handler' field. Please file a bug at https://github.com/xamarin/xamarin-macios/issues/new.
```
https://github.com/xamarin/xamarin-macios/pull/4884 introduced the logic of only building certain `RunTestTask`.
This was meant to disable iOS Extensions as part of a fix to https://github.com/xamarin/maccore/issues/1008.
However this didn't quite work and iOS extensions were still running (and failing).
The reason being that `BuildOnly` was set to a `RunDeviceTask` that's added to a list which is then given to `CreateTestVariations` which creates new instances of `RunDeviceTask`.
We now propagate `BuildOnly` to the new variation instance.
According to Rolf it's fine to always add since the native linker will
figure out if it's really needed and so customers don't need to do
anything when using -all_load.
Mono started using System.IO.File from CoreFX and it has a different
behavior for File.Copy() when the target is a directory:
It just puts the file into the directory instead of raising an exception.
In order to fix the MT1015 test we just check ourselves whether the target
is a directory.
* [XHarness] Ignore some tests that fail on device.
Added the ignore, which can be later removed on the new mono 2019-02
since the issues do not happen there.
Fixes: https://github.com/xamarin/maccore/issues/1495
* [XHarness] Ignore corlib tets failing on devices.
Added the required ignores to get the devices green and workaround mono
issue https://github.com/mono/mono/issues/13641
Up to this commit the test dlls used for the bcl tests were from iOS. Since
the Mono SDK provides the dlls for both missing platforms (TvOS and
WatchOS) we can now use the correct path for the dlls.
There is a small trick to minimize the project generation, since there
is a simple stirng.Replace, the logic now checks the platform under
test and does:
* TvOS - Goes from monotouch_TEST_NAME to monotouch_tv_TEST_NAME
* WatchOS - Gores from monotouch_TEST_NAME to monotouch_watch_TEST_NAME
The internal runtime type was renamed: MonoModule -> RuntimeModule, MonoAssembly -> RuntimeAssembly
Also linker got smarter and removed unecessary types for WebKit_NSProxy.
This commit improves the state of the BCL testing in the following ways:
1. Improve the device tets running. Less apps, faster results.
2. WatchOS apps are left as they were to ensure that we do not have deplouyment/run issues.
We now support the ignore files per assembly name to simplify the
tracking of the ignored tests. All
```
/Users/poupou/git/master/xamarin-macios/tools/linker/MonoTouch.Tuner/RemoveBitcodeIncompatibleCodeStep.cs(14,7): warning CS0105: The using directive for 'Xamarin.Linker' appeared previously in this namespace [/Users/poupou/git/master/xamarin-macios/tools/mtouch/mtouch.csproj]
```
This also centralize other interpreter checks and options in the same
location (making it easier to read / update).
* Warn and switch the REPL if the interpreter is enabled on simulator
Why ? It's confusing to build the same code using different options for
simulator and devices. This is what happens if you try to use features
like `dynamic` or `System.Reflection.Emit`.
So instead of an error, we warn that the interpreter is not supported
and switch to the existing REPL mode.
The JIT remains the only option for the simulator but it allows testing
features without a device.
* Fail early if the interpreter is used on 32bits [1]
The current interpreter only works on 64 bits (so ARM64). However the
error won't be reported, back to the developer, until deployment time.
This temporary [1] fix spot the condition very early and report an error
```
error MT0099 : Internal error : The interpreter is currently only available for 64 bits.
```
instead of the current one at deploy time
```
IncorrectArchitecture: Failed to find matching arch for 32-bit Mach-O input file /private/var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.tNKDlx/extracted/X.app/X
error MT1006: Could not install the application 'X.app' on the device 'Mercure': AMDeviceSecureInstallApplicationBundle returned: 0xe8000087 (kAMDIncorrectArchitectureError).
Application could not be uploaded to the device.
```
[1] https://github.com/mono/mono/issues/9871
* [tests] Fix/renumbered MT0138
The test was using simulator + interpreter which is not _really_
possible, we use REPL in that case - so we're now checking if
assemblies were specified with `--interpreter` to cover both cases.
Also 0138 was already used by `mmp` and the warning was **not**
registered or documented in the errors documents. To avoid
confusion it has been renumbered to 0142 and documented.