* Bump VSMac to 8.1.0.2742 to fix msbuild issues (#6279)
* Bump VSMac to 8.1.0.2742 to fix msbuild issues
This is required to get the support for the msbuild `ToolsVersion`
change from `15.0` to `Current`.
* [tests][msbuild] Fix Binding resources test with updated msbuild
Test failure with updated msbuild and vsmac 8.1:
```
Xamarin.iOS.Tasks.NativeReferencesNoEmbedding("iPhone").ShouldNotUnnecessarilyRebuildBindingProject(True)
Binding project build did not create package?
Expected: True
But was: False
at Xamarin.iOS.Tasks.NativeReferencesNoEmbedding.ShouldNotUnnecessarilyRebuildBindingProject (System.Boolean framework) [0x000a0] in <74b8f7d8a53e40109916d305bb4d7403>:0
at (wrapper managed-to-native) System.Reflection.RuntimeMethodInfo.InternalInvoke(System.Reflection.RuntimeMethodInfo,object,object[],System.Exception&)
at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo cul
ture) [0x0006a] in <0519fa732e8845b6a809ce9180f541db>:0
```
The test builds the project multiple times. Before the 3rd build, the project
file's timestamp is updated and expects that the binding package will be
rebuilt. But it is not, because the target `_CreateBindingResourcePackage`
doesn't depend on that project file. So, add that to the target inputs.
* [nuget] Use xibuild to run nuget
Fix errors seen during `nuget restore` for tests:
```
Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xammac_tests/xammac_tests.csproj(213,3): error MSB4024: The imported project file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.CSharp.targets" could not be loaded. Could not find file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.CSharp.targets"
```
* [xibuild] Fix incorrect mscorlib.dll being used (#6068)
* [xibuild] Fix incorrect mscorlib.dll being used
The `GuiUnit_NET_4_5` project, when built with `xibuild` uses the wrong `mscorlib.dll`.
From https://github.com/xamarin/xamarin-macios/issues/5760#issuecomment-472457202 :
```
- mscorlib.dll is being used from mono/4.5 and the other system assemblies are from mono/4.5-api
- GuiNet* project is built with xibuild
What is happening here is:
xibuild sets[1] `SetToolsetProperty ("TargetFrameworkRootPath", FrameworksDirectory + Path.DirectorySeparatorChar);`
which points to `/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/xbuild-frameworks`.
This causes $(FrameworkPathOverride) to be set[2] to `/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/xbuild-frameworks/.NETFramework/v4.5`,
but that doesn't have a mscorlib.dll, so it gets reset[3] to /Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5/.
If we don't set TargetFrameworkRoothPath, then we get `FrameworkPathOverride = /Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5-api`,
causing `_ExplicitReference=/Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5-api/mscorlib.dll`(correct one) to be used.
```
Fixes https://github.com/xamarin/xamarin-macios/issues/5760
1. https://github.com/xamarin/xamarin-macios/blob/master/tools/xibuild/Main.cs#L209
2. https://github.com/mono/msbuild/blob/xplat-master/src/Tasks/Microsoft.Common.CurrentVersion.targets#L79
3. https://github.com/mono/msbuild/blob/xplat-master/src/Tasks/Microsoft.Common.CurrentVersion.targets#L84
* Revert "Workaround https://github.com/xamarin/xamarin-macios/issues/5760 in generator csproj"
This reverts commit 9bd927bb7f.
The previous commit for xibuild removes the need for this.
* [xibuild] Handle "incorrectly" cased msbuild property names (#6202)
msbuild property names are case insensitive. While generating the custom
app.config, in `SetToolsetProperty(..)` we try to update the property if
it already exists. But the name lookup was case sensitive, thus causing
the lookup to fail, resulting in two entries for the same property name
differing only in case. Eg. `MSBuildSDKsPath` vs `MSBuildSdksPath`.
Fixed to ignore case.
Fixes https://github.com/mono/mono/issues/14765 .
* [tests] Minor refactor to get better Xcode version parsing.
* Rename Configuration.XcodeVersion to XcodeVersionString.
* Add Configuration.XcodeVersion a parsed Version instane of XcodeString.
* [tests] Ignore all 'MT0099: Not linking with WatchKit because Xcode 11 beta 1' warnings in tests.
* [tests] Adjust min OS version tests for Xcode 11b1.
* [tests] Adjust tests for changes in 'nm' output.
* [tests] Adjust tests for name changes in Clang.
* [tests] Adjust tests for changes in ld warning format.
* [msbuild] 'metal' and 'metallib' aren't in PATH anymore, so use xcrun to execute them.
* [msbuild] Fix DevicePlatformBinDir for the Metal and MetalLib targets on iOS.
Also set the SDKROOT variable, otherwise metal and metallib don't work
properly, and revert the previous attempt at a fix (use xcrun).
* [tests] Simplify version parsing code to not version parse anymore.
* [tests] Add FIXME for once Apple fixes the WatchKit disappearance.
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.
Rolf Bjarne Kvinge
Bernhard Urban
monojenkins
Alexander Köplinger
Vincent Dondain
Sebastien Pouliot
Manuel de la Pena
Alex Soto