This allows the optimization to be disabled in cases where one, or
many, a custom attribute(s) are required by the application at runtime.
While not ideal disabling this single step is much better than disabling
linking for the whole application.
A better approach is described in https://github.com/xamarin/xamarin-macios/issues/6048
but this configuration optimization makes sense independently of it.
Fix https://github.com/xamarin/xamarin-macios/issues/3655
We build for both armv7 and arm64, and the failure we're looking for can
happen with either architecture. The order in which the architectures are
built is random, and mtouch will fail once the first error occurs, which means
that we can't assert that the failure comes from the arm64 build, since the
armv7 build might have been executed first (and triggered the error).
So just don't assert that the expected error message contains the
architecture, which makes the assert valid for both armv7 and armv64.
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.
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.
mscorlib.dll now has InternalsVisibleTo to System.Net.Http.dll which causes
> Friend access was granted to `System.Net.Http, PublicKeyToken=b03f5f7f11d50a3a', but the output assembly is named `System.Net.Http, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'.
Switch to System.Xml.dll instead for these tests.
document it and adjust the optimization tests.
This allows the optimization to be:
* disabled (if ever needed) on fully AOT'ed applications
* re-enabled for the interpreter (at your own risk)
After commit 2619d8f5ca the System.Core
tests does not longer exists. Which makes the mtouch test that depends
on it, fail too. This changes the test to use a present test.
* Add a Runtime.IsARM64CallingConvention property.
Determining whether we should use the ARM64 calling convention in P/Invokes
gets more complicated with ARM64_32 (which for our purposes is a 32-bit
architecture).
So add a property on the Runtime class to avoid code duplication, and teach
the linker to optimize any calls to this property to a constant value whenever
possible (and the method is marked as optimizable).
Also change our code to use this new property, and make the corresponding
methods optimizable.
Some shuffling in mmp was required, which meant a little bit more code is now
shared between mtouch and mmp.
* Coding style.
* Test tweaks.
* Improve comment.
* Document new optimization
* Move ILReader to shared linker test code location.
* Disable inlining on armv7k.
* Change IsARM64CallingConvention to a read-only field.
We can give the AOT compiler a constant value for a read-only field, so that
the AOT compiler optimizes away the call to the field by using the constant
value.
This commit does not implement this change for the AOT compiler, but using a
read-only field makes it easy to implement it in the future.
Fixesxamarin/maccore#1392
* [tests|mtouch] armv7 to arm64 in a couple of device build tests
Our tests are currently failing when building for device + don't Link linker
configuration + armv7[1] so we modified said tests to do arm64 instead.
For more context see: https://github.com/xamarin/xamarin-macios/issues/5512
[1]:
```
Xamarin.MTouch.Registrar(Dev,DontLink,Static,"") : Expected execution to succeed, but exit code was 1, and there were 1 error(s): build
error MT5106: Could not compile the file(s) '/private/var/folders/9t/bhhqghxd4131b5k43v0yk7yc0000gn/T/mtouch.cache/u102nsmt.f5b/armv7/Xamarin.iOS.dll.s'. Please file a bug report at http://bugzilla.xamarin.com
at Xamarin.Tests.BundlerTool.AssertExecute (System.String message) [0x00095] in :0
at Xamarin.MTouchTool.AssertExecute (Xamarin.MTouchAction action, System.String message) [0x0000d] in :0
at Xamarin.MTouch.Registrar (Xamarin.Target target, Xamarin.Tests.LinkerOption linker, Xamarin.Tests.RegistrarOption registrar, System.String abi) [0x0005a] in :0
Xamarin.MTouch.Registrar(Dev,DontLink,Dynamic,"") : Expected execution to succeed, but exit code was 1, and there were 1 error(s): build
error MT5106: Could not compile the file(s) '/private/var/folders/9t/bhhqghxd4131b5k43v0yk7yc0000gn/T/mtouch.cache/ma2r71ts.k3p/armv7/Xamarin.iOS.dll.s'. Please file a bug report at http://bugzilla.xamarin.com
at Xamarin.Tests.BundlerTool.AssertExecute (System.String message) [0x00095] in :0
at Xamarin.MTouchTool.AssertExecute (Xamarin.MTouchAction action, System.String message) [0x0000d] in :0
at Xamarin.MTouch.Registrar (Xamarin.Target target, Xamarin.Tests.LinkerOption linker, Xamarin.Tests.RegistrarOption registrar, System.String abi) [0x0005a] in :0
Xamarin.MTouch.TestCaseMismatchedAssemblyName : Expected execution to succeed, but exit code was 1, and there were 1 error(s): build: dontlink
error MT5106: Could not compile the file(s) '/private/var/folders/9t/bhhqghxd4131b5k43v0yk7yc0000gn/T/mtouch.cache/2i0rdomc.jnq/armv7s/Xamarin.iOS.dll.s'. Please file a bug report at http://bugzilla.xamarin.com
at Xamarin.Tests.BundlerTool.AssertExecute (System.String message) [0x00095] in :0
at Xamarin.MTouchTool.AssertExecute (Xamarin.MTouchAction action, System.String message) [0x0000d] in :0
at Xamarin.MTouch.TestCaseMismatchedAssemblyName () [0x0021e] in :0
```
* Fix indentation
* [linker] Remove non-bitcode compatible code, and show a warning.
Remove code not currently compatible with bitcode and replace it with an
exception instead (otherwise we'll assert at runtime).
Also show a warning when we detect this.
This is quite helpful when looking at watch device test runs to filter out
failures we already know about.
This fixes point #2 in #4763.
* Improve documentation.
* Simplify linker code by using a substep.
* Fix whitespace issues.
* Improve reporting.
* Add support for reporting more than one MT2105 at the same time when making
the errors instead of warnings.
* Only report MT2105 for methods that haven't been linked away.
* Format the error message nicer for properties.
* Tweak a bit for warning tests to pass.
* Use ExceptionalSubStep to provide better error information.
* Adjust where linker warnings/errors are reported from to avoid a NullReferenceException.
* [tests] Use latest version of NUnit for test projects to get support for parallelized tests.
* [xharness] Automatically find the correct nunit-console executable for NUnit tests.
This is usually not a problem, because these variables are already set when
running from the command-line or xharness. However, it shows up when running
tests directly from VSfM.