Exclude some code in Metal tasks when building the tests to avoid the
significant complexity it would be to add the required source files to the
mtouch test project.
- Fixes#4576: [xcode10] 'Metal Game' fails to build. (https://github.com/xamarin/xamarin-macios/issues/4576)
In Xcode 10 Apple moved the "metal" binary from `/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/usr/bin/metal` to `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal`.
- https://github.com/xamarin/xamarin-macios/issues/3367
- App Store will now fail builds if you add in a 32-bit dylib
- If you are a 32-bit app you don't need the 64-bit part of your fat
dylib anyway
- Add --optimize=-trim-architectures to allow customization of behavior, as not everyone
uses app store
In addition, while writing tests for this is was noticed that mmp tests did not "really" run Release configuration correctly in most cases. Fixing this turned out to be a bit of a pain, but necessary to correctly test this (and other things).
- Turns out that /p:configuration:debug is not sufficient to tell mmp to
do the right thing
- That, in most projects, sets the DebugSymbols property, which really
is what is checked.
- However, two of our projects did not have that, so we always did
release mmp work.
- Removed configuration property for tests and added real "Release"
configuration option
* [linker] Optimize calls to BlockLiteral.SetupBlock to inject the block signature.
Optimize calls to BlockLiteral.SetupBlock[Unsafe] to calculate the block
signature at build time, and inject it into the call site.
This makes block invocations 10-15x faster (I've added tests that asserts at
least an 8x increase).
It's also required in order to be able to remove the dynamic registrar code in
the future (since calculating the block signature at runtime requires the
dynamic registrar).
* [mtouch/mmp] Add support for reporting errors/warnings that point to the code line causing the error/warning.
Add support for reporting errors/warnings that point to the code line causing
the error/warning by adding ErrorHelper overloads that take the exact
instruction to report (previously we defaulted to the first line/instruction
in a method).
* [tests] Add support for asserting filename/linenumber in warning messages.
* Make all methods that manually create BlockLiterals optimizable.
* [tests] Create a BaseOptimizeGeneratedCodeTest test that's included in both XI's and XM's link all test.
* [tests] Add link all test (for both XI and XM) to test the BlockLiteral.SetupBlock optimization.
* [tests] Add mtouch/mmp tests for the BlockLiteral.SetupBlock optimization.
* [tests][linker] Make the base test class abstract, so tests in the base class aren't executed twice.
* [tests][linker] Don't execute linkall-only tests in linksdk.
The optimization tests only apply when the test assembly is linked, and that
only happens in linkall, so exclude those tests in linksdk.
* [tests][mmptest] Update test according to mmp changes.
Fixes these test failures:
1) Failed : Xamarin.MMP.Tests.MMPTests.MM0132("inline-runtime-arch")
The warning 'MM0132: Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.' was not found in the output:
Message #1 did not match:
actual: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.'
expected: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.'
Message #2 did not match:
actual: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.'
expected: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.'
2) Failed : Xamarin.MMP.Tests.MMPTests.MM0132("foo")
The warning 'MM0132: Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.' was not found in the output:
Message #1 did not match:
actual: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.'
expected: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.'
Message #2 did not match:
actual: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.'
expected: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.'
* [tests][linker] Fix typo.
Fixes this test failure:
1) SetupBlock_CustomDelegate (Linker.Shared.BaseOptimizeGeneratedCodeTest.SetupBlock_CustomDelegate)
Counter
Expected: 1
But was: 2
* [registrar] Minor adjustment to error message to match previous (and better) behavior.
Fixes this test failure:
1) Failed : Xamarin.Registrar.GenericType_WithInvalidParameterTypes
The error 'MT4136: The registrar cannot marshal the parameter type 'System.Collections.Generic.List`1<U>' of the parameter 'arg' in the method 'Open`1.Bar(System.Collections.Generic.List`1<U>)'' was not found in the output:
Message #1 did not match:
actual: 'The registrar cannot marshal the parameter type 'System.Collections.Generic.List`1<Foundation.NSObject>' of the parameter 'arg' in the method 'Open`1.Bar(System.Collections.Generic.List`1<U>)''
expected: 'The registrar cannot marshal the parameter type 'System.Collections.Generic.List`1<U>' of the parameter 'arg' in the method 'Open`1.Bar(System.Collections.Generic.List`1<U>)''
* [docs] mmp shows MM errors/warnings.
* [docs] Improve according to reviews.
* [tests] Fix merge failure causing test duplication.
* [tests] Share supporting code between the mtouch and mmp tests.
Create a new class 'BundlerTool', which now contains most of the code in
MTouchTool that's also applicable to mmp (and the new MmpTool class).
This will make it easier to share tests between the mtouch and mmp tests.
Some tweaks are still probably required, but this should get us most of the
way.
* [tests] Fix generator tests after changes in shared test code.
* [tests] Add new file to the MSBuild/XM tests.
The parsing done by `System.Version` does not accept a major-only string,
e.g. providing "11" would throw an exception.
Since people generally refer version as iOS 11 (and not iOS 11.0) this
is, at best, a nuisance. Xcode toolchain accept "11" as a valid string.
The first part of message was updated to show both the option name and
the (user provided) value.
The 2nd part remain the text of the .net exception message, i.e. what
`Version.Parse` tells you when it validates the string. Seeing the input
value should make it more obvious for other, incorrect version strings.
reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=60280
Don't assume that a marked method has a caller, since a method can be marked
from XML as well.
This fixes a NullReferenceException:
> error : Could not link assemblies.
> Type: `System.Reflection.RuntimeParameterInfo`
> Assembly: `mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e`
> Reason: Object reference not set to an instance of an object
> --- inner exception
> System.NullReferenceException: Object reference not set to an instance of an object (Aufgaben-ID: 165)
> at MonoTouch.Tuner.MonoTouchMarkStep.MarkMethod (Mono.Cecil.MethodReference reference) [0x0004f] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/tools/linker/MonoTouch.Tuner/MonoTouchMarkStep.cs:105
> at Mono.Linker.Steps.MarkStep.MarkMethodCollection (System.Collections.IEnumerable methods) [0x00017] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/external/linker/linker/Mono.Linker.Steps/MarkStep.cs:1163
> at Mono.Linker.Steps.MarkStep.MarkMethods (Mono.Cecil.TypeDefinition type) [0x0000b] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/external/linker/linker/Mono.Linker.Steps/MarkStep.cs:1157
> at Xamarin.Linker.Steps.MobileMarkStep.MarkMethods (Mono.Cecil.TypeDefinition type) [0x0000b] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/tools/linker/MobileMarkStep.cs:123
> at Mono.Linker.Steps.MarkStep.ApplyPreserveInfo (Mono.Cecil.TypeDefinition type) [0x0004a] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/external/linker/linker/Mono.Linker.Steps/MarkStep.cs:1102
> at Mono.Linker.Steps.MarkStep.MarkType (Mono.Cecil.TypeReference reference) [0x001ee] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/external/linker/linker/Mono.Linker.Steps/MarkStep.cs:607
> at Xamarin.Linker.Steps.MobileMarkStep.MarkType (Mono.Cecil.TypeReference reference) [0x00001] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/tools/linker/MobileMarkStep.cs:71
> at Xamarin.Linker.Steps.CoreMarkStep.MarkType (Mono.Cecil.TypeReference reference) [0x00046] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/tools/linker/CoreMarkStep.cs:156
> at MonoTouch.Tuner.MonoTouchMarkStep.MarkType (Mono.Cecil.TypeReference reference) [0x00001] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/tools/linker/MonoTouch.Tuner/MonoTouchMarkStep.cs:84
> at Mono.Linker.Steps.MarkStep.MarkType (Mono.Cecil.TypeReference reference) [0x0007d] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/external/linker/linker/Mono.Linker.Steps/MarkStep.cs:566
> at Xamarin.Linker.Steps.MobileMarkStep.MarkType (Mono.Cecil.TypeReference reference) [0x00001] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/tools/linker/MobileMarkStep.cs:71
> at Xamarin.Linker.Steps.CoreMarkStep.MarkType (Mono.Cecil.TypeReference reference) [0x00046] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/tools/linker/CoreMarkStep.cs:156
> at MonoTouch.Tuner.MonoTouchMarkStep.MarkType (Mono.Cecil.TypeReference reference) [0x00001] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/tools/linker/MonoTouch.Tuner/MonoTouchMarkStep.cs:84
> at Mono.Linker.Steps.MarkStep.InitializeType (Mono.Cecil.TypeDefinition type) [0x0005b] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/external/linker/linker/Mono.Linker.Steps/MarkStep.cs:94
> at Mono.Linker.Steps.MarkStep.InitializeAssembly (Mono.Cecil.AssemblyDefinition assembly) [0x00025] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/external/linker/linker/Mono.Linker.Steps/MarkStep.cs:81
> at Mono.Linker.Steps.MarkStep.Initialize () [0x00016] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/external/linker/linker/Mono.Linker.Steps/MarkStep.cs:73
> at Mono.Linker.Steps.MarkStep.Process (Mono.Linker.LinkContext context) [0x00008] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/external/linker/linker/Mono.Linker.Steps/MarkStep.cs:66
> at Xamarin.Linker.Steps.MobileMarkStep.Process (Mono.Linker.LinkContext context) [0x00001] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/tools/linker/MobileMarkStep.cs:33
> at Xamarin.Linker.Steps.CoreMarkStep.Process (Mono.Linker.LinkContext context) [0x00017] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/tools/linker/CoreMarkStep.cs:26
> at MonoTouch.Tuner.MonoTouchMarkStep.Process (Mono.Linker.LinkContext context) [0x0001d] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/tools/linker/MonoTouch.Tuner/MonoTouchMarkStep.cs:36
> at Mono.Linker.Pipeline.Process (Mono.Linker.LinkContext context) [0x00023] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/external/linker/linker/Mono.Linker/Pipeline.cs:128
> at MonoTouch.Tuner.Linker.Process (MonoTouch.Tuner.LinkerOptions options, MonoTouch.Tuner.MonoTouchLinkContext& context, System.Collections.Generic.List`1[Mono.Cecil.AssemblyDefinition]& assemblies) [0x000e0] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/tools/mtouch/Tuning.cs:82
https://bugzilla.xamarin.com/show_bug.cgi?id=60176
TL&DR: This is *how* it should be done and tested, it's not complete
(single, simple case) nor the most interesting case ;-)
The trick is to make sure each case is covered by tests so a mono
_bump_ won't give us a BCL that does not conform to what the linker
expect.
What's the impact ?
1. There is the expected reduction of metadata in mscorlib. Since both
methods don't call other API there's no indirect effect (removal).
--- before 2017-01-15 11:12:44.000000000 -0500
+++ after 2017-01-15 11:12:56.000000000 -0500
@@ -13166,9 +13166,6 @@
System.Void System.Security.SecurityException::.ctor(System.Runtime.Serialization.SerializationInfo,System.Runtime.Serialization.StreamingContext)
System.Void System.Security.SecurityException::.ctor(System.String)
System.Void System.Security.SecurityException::GetObjectData(System.Runtime.Serialization.SerializationInfo,System.Runtime.Serialization.StreamingContext)
-System.Boolean System.Security.SecurityManager::CheckElevatedPermissions()
-System.Security.SecurityManager
-System.Void System.Security.SecurityManager::EnsureElevatedPermissions()
System.Security.SecurityRulesAttribute
System.Security.SecurityRuleSet System.Security.SecurityRulesAttribute::m_ruleSet
System.Void System.Security.SecurityRulesAttribute::.ctor(System.Security.SecurityRuleSet)
2. There is no visible size change (even with #1) in mscorlib.dll due to
padding (compiler /filealign)
mscorlib.dll 793,600 793,600 0 0.00 %
3. there's a *very* small reduction of mscorlib.*.aotdata size
mscorlib.armv7.aotdata 717,264 717,216 -48 -0.01 %
mscorlib.arm64.aotdata 712,840 712,704 -136 -0.02 %
AOT data *.aotdata 6,460,064 6,459,880 -184 0.00 %
4. there's no change in executable size - normal as the AOT compiler has
_likely_ already doing the same optimization (before this commit)
Executable 29,270,272 29,270,272 0 0.00 %
Full comparison: https://gist.github.com/spouliot/0464c8fa3a92b6486dfd90595d9eb718
This makes us only put packages in one directory (saves disk space and time),
and it also makes project files in multiple solutions work properly
(mtouch.csproj is in tests/tests.sln and tests/mtouch/mtouch.sln).
* [mtouch/tests] Add TimingTests
- New MLaunchTool.
- AppLaunchTime (mlaunch): time to launch an application on the simulators.
How it works: we first open the simulator by launching a dummy app. This allows us to detect if there are any launch watchdogs.
Therefore, for consistency, all measurements are done with the simulator already open.
In the case of the AppLaunchTime test, we build the app with the default config and launch it. It's automatically killed by the simulator
because it does not have a valid entry point but this is fine because it also kills the process and lets us stop the stopwatch.
We then simply log the time performance.
Rolf Bjarne Kvinge
Vincent Dondain
Chris Hamons
Sebastien Pouliot
Timothy Risi
Vincent Dondain