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.
Deserialize cached Objective-C class symbols to match how the objects looked
before serialization. This means storing the Objective-C class name in the
Symbol.ObjectiveCName field, and not the Symbol.Name field.
Fixes https://github.com/xamarin/xamarin-macios/issues/5467.
We can't share native code between apps and app extensions if the interpreter
settings differ between them, so detect this scenario and automatically
disable native code sharing.
Fixes https://github.com/xamarin/xamarin-macios/issues/5365.
* [xibuild] Add support for /verbose, and use it accordingly.
Also stop using xibuild when it's not needed.
* Use the same verbosity for xibuild as we do for xbuild/msbuild.
* [tests] Add test to ensure LLVM succeeds on watchOS for every assembly we ship.
References:
* https://github.com/mono/mono/issues/12131: LLVM failed for 'UIEdgeInsets.Equals': opcode r4_cneq
* https://github.com/mono/mono/issues/12130: [watchOS] MT3001: Could not AOT the assembly mscorlib.dll
* https://github.com/xamarin/xamarin-macios/issues/4763: [RFC] Improve handling of filter clauses with LLVM/Bitcode
* https://bugzilla.xamarin.com/show_bug.cgi?id=58209: LLVM/bitcode can't handle filter clauses
* LLVM failure in mscorlib.dll is now fixed.
* Revert "LLVM failure in mscorlib.dll is now fixed."
This reverts commit ace3c930a9.
* [tests] Run mtouch tests inprocess.
Fixes a remoting exception:
System.Runtime.Remoting.RemotingException: Cannot create channel sink to connect to URL fff8ce5c_3219_4dd0_941f_500dd49e02a5/94f23f2_4.rem. An appropriate channel has probably not been registered.
Server stack trace:
at System.Runtime.Remoting.RemotingServices.GetClientChannelSinkChain (System.String url, System.Object channelData, System.String& objectUri) [0x00019] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Remoting.RemotingServices.GetOrCreateClientIdentity (System.Runtime.Remoting.ObjRef objRef, System.Type proxyType, System.Object& clientProxy) [0x0001d] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Remoting.RemotingServices.GetRemoteObject (System.Runtime.Remoting.ObjRef objRef, System.Type proxyType) [0x00000] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Remoting.RemotingServices.GetProxyForRemoteObject (System.Runtime.Remoting.ObjRef objref, System.Type classToProxy) [0x0001b] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Remoting.RemotingServices.Unmarshal (System.Runtime.Remoting.ObjRef objectRef, System.Boolean fRefine) [0x0007a] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Remoting.RemotingServices.Unmarshal (System.Runtime.Remoting.ObjRef objectRef) [0x00000] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Remoting.ObjRef.GetRealObject (System.Runtime.Serialization.StreamingContext context) [0x0000f] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Serialization.ObjectManager.ResolveObjectReference (System.Runtime.Serialization.ObjectHolder holder) [0x00010] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Serialization.ObjectManager.DoFixups () [0x0007f] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize (System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Runtime.Serialization.Formatters.Binary.__BinaryParser serParser, System.Boolean fCheck, System.Boolean isCrossAppDomain, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x00077] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Boolean fCheck, System.Boolean isCrossAppDomain, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x000a2] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Boolean fCheck, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x00000] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.DeserializeMethodResponse (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x00000] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage (System.Runtime.Remoting.Messaging.IMessage msg) [0x00083] in <dcf627861d9e44ce818b79d685496eeb>:0
Exception rethrown at [0]:
at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_remoting_wrapper(intptr,intptr)
at (wrapper remoting-invoke) NUnit.Engine.Agents.RemoteTestAgent.Load()
at NUnit.Engine.Runners.ProcessRunner.LoadPackage () [0x00040] in <28c9cb3cd2594f14ad436553a9b77f5d>:0
at NUnit.Engine.Runners.AbstractTestRunner.Load () [0x00000] in <28c9cb3cd2594f14ad436553a9b77f5d>:0
at NUnit.Engine.Runners.MasterTestRunner.LoadPackage () [0x0006b] in <28c9cb3cd2594f14ad436553a9b77f5d>:0
at NUnit.Engine.Runners.MasterTestRunner..ctor (NUnit.Engine.IServiceLocator services, NUnit.Engine.TestPackage package) [0x0007a] in <28c9cb3cd2594f14ad436553a9b77f5d>:0
at NUnit.Engine.TestEngine.GetRunner (NUnit.Engine.TestPackage package) [0x0001e] in <28c9cb3cd2594f14ad436553a9b77f5d>:0
at NUnit.ConsoleRunner.ConsoleRunner.RunTests (NUnit.Engine.TestPackage package, NUnit.Engine.TestFilter filter) [0x00095] in <93782c327b3c4ab5aae551528dfe1cae>:0
at NUnit.ConsoleRunner.ConsoleRunner.Execute () [0x000b6] in <93782c327b3c4ab5aae551528dfe1cae>:0
at NUnit.ConsoleRunner.Program.Main (System.String[] args) [0x001b5] in <93782c327b3c4ab5aae551528dfe1cae>:0
* [xharness] Run mtouch tests in-process.
* [tests] Don't run the LLVM watchOS tests if we didn't build for device.
* [tests] Update NoLLVMFailuresInWatchOS known failures according to latest mono bump.
Fixesxamarin/xamarin-macios#4107
We currently generate invalid registrar code when we get invalid input
in 'Adopts' attribute, this can happen because 'Adopts' can take a
plain string. We now generate a better error MT4177 instead of
generating invalid registrar.m/h code.
* [runtime] Clean up public symbols. Fixes#5124.
Clean up public symbols, by:
* Symbols that don't need to be public (most of them), can be private.
* Prefix all public symbols with `xamarin_`.
* Add a test to ensure we don't introduce new public symbols.
* Use C symbols instead of mangled C++ symbols, since those are easier to
handle in the test.
This minimizes the chance of getting into a symbol clash with another native library.
Fixes https://github.com/xamarin/xamarin-macios/issues/5124.
* Some test fixes.
* xibuild: New wrapper tool to run msbuild or managed executables
MSBuild supports fallback paths for projects imported using
`$(MSBuildExtensionsPath)`, but these must be specified explicitly in
the app.config of the main executable. There was a PR to allow use of
properties for this in the app.config, but that was not accepted
upstream.
This is required for being able to:
1. build projects with msbuild against the in-tree XI/XM build output
2. and to run nunit tests against the same.
For this we introduce a new tool, `xibuild`, based on XA's `xabuild`.
This supports the fallback paths to be specified via the environment variable
`MSBuildExtensionsPathFallbackPathsOverride`[1].
It essentially operates in 3 modes:
1. `xibuild -c /path/to/foo.exe`
Generates /path/to/foo.exe.config with the fallback paths inserted into that.
2. `xibuild -- /v:diag /path/to/project.csproj`
Runs msbuild with the arguments after `--` with a custom app.config based on
`MSBuild.dll.config`, with the fallback paths correctly inserted.
This is in a temporary file and the original config file is not touched.
3. `xibuild -t -- /path/to/managed_tool.exe args`
Generates `/path/to/managed_tool.exe.config` based on `MSBuild.dll.config` with
the fallback paths inserted, and runs `managed_tool.exe` with the arguments.
The default is to overwrite the config file.
But there is also a switch to merge it with an existing config file.
--
1. Value of the environment variable $MSBuildExtensionsPathFallbackPathsOverride
is prepended to any existing list of search paths in `MSBuild.dll.config`, IOW,
it takes precedence. So, the order of lookup becomes:
- Value of the property `$(MSBuildExtensionsPath)`
- Value of the environment variable `$MSBuildExtensionsPathFallbackPathsOverride`
- /Library/Frameworks/Mono.framework/External/xbuild on macOS
* Integrate use of `xibuild` with the tests
Update all uses of `msbuild` and invocations of tools like nunit that
might depend on using the in-tree builds to use `xibuild`.
* xibuild: Move help descriptions to OptionSet itself.
Restoring the mtouch.csproj makes nuget try to restore Mono.Cecil.csproj as
well, which doesn't work.
So just restore what's listed in our packages.config instead.
* Bump to mono:2018-06
* Bump mono
* Updates compression to work with the public span
* Bump mono
* Fixes pointer check logic in Deflater
* Bump mono
* Fixes pointer check logic in Deflater
* Bump mono
* Bump Mono
* [runtime] always use `mono_jit_set_aot_mode` (#4491)
`mono_jit_set_aot_only` is deprecated and accidentally broke with
https://github.com/mono/mono/pull/7887
This should fix device tests with `mono-2018-06`
* Testing with Zoltan's patch
* Include libmono-system-native on Xamarin.Mac
* Bump Mono
Commit list for mono/mono:
* mono/mono@7bcda192a0 Bump llvm to release_60/fc854b8ec5873d294b80afa3e6cf6a88c5c48886. (#9786). (#9804)
* mono/mono@23e95ec7ad Apply F# portable pdb debug fix for pinvokes & bump (#9797)
* mono/mono@295f6d32af [2018-06] [MacOS] On Mac, use the copyfile API to copy files (#9696)
Diff: 7d5f4b6136...7bcda192a0
* Revert 4bacab3d5c, it doesn't fix the ios aot problems.
* Bump mono
* [tests] Adjust the MT0137 test for mcs change in behavior.
Starting with mono 5.16 mcs will now add assembly references when the assembly
is only used in attributes (this was already the case for csc in both 5.14 and
5.16, so it seems to be a compatibility change).
Adjust the MT0137 test accordingly.
* [msbuild] Fix parsing of json parser errors to handle trailing periods in the error message.
Fixes this test:
1) Test Failure : Xamarin.iOS.Tasks.Bug60536.TestACToolTaskCatchesJsonException
ColumnNumber
Expected: 2
But was: 0
* Bump mono
* [builds] Install the old llvm binaries into the LLVM36 directory and make the 32 bit builds use that.
* Bump mono
* Bump mono
* [jenkins] Don't give VSTS a fake branch. (#4667)
Something in VSTS changed, and now fake branch names don't work anymore.
So instead use real branch names (and for pull requests I've created a
'pull-request' branch we can use).
* Assembly.LoadFile accepts only absolute path
* [linker] Add new Facade (System.Threading.Tasks.Extensions).
Fixes these MTouch test failures:
1. Xamarin.Linker.SdkTest.iOS_Unified : Facades
Expected:
But was: < "System.Threading.Tasks.Extensions" >
2. Xamarin.Linker.SdkTest.tvOS : Facades
Expected:
But was: < "System.Threading.Tasks.Extensions" >
3. Xamarin.Linker.SdkTest.watchOS : Facades
Expected:
But was: < "System.Threading.Tasks.Extensions" >
* [mono-sdks] Necessary changes to unify the LLVM provisioning for both iOS and Android. (#4732)
* Bump Mono
* [mtouch] add mixed-mode support (#4751)
* [mtouch] add --interp-mixed option
When enabling this option, mtouch will AOT compile `mscorlib.dll`. At
runtime that means every method that wasn't AOT'd will be executed by
the runtime interpreter.
* [mtouch] Add support to --interpreter to list the assemblies to (not) interpret.
* [msbuild] Simplify interpreter code to use a single variable.
* Fix whitespace.
* [mtouch] Move mtouch-specific code to mtouch-specific file.
* [msbuild] An empty string is a valid value for 'Interpreter', so make it a non-required property.
* [mtouch] Add sanity check for aot-compiling interpreted assemblies.
* Bump Mono
* [linker] Updates SDKs facades list
* Bump mono
* [msbuild] Adds facades which might override default nuget version to framework list
The collision resolver task reads them from here https://github.com/dotnet/sdk/blob/master/src/Tasks/Common/ConflictResolution/FrameworkListReader.cs
* Bump to a VSfM version that can build XM Classic projects.
* Add support for delegates as return values in protocol members. Fixes#4102.
This required a few changes:
* The generator now emits the DelegateProxy attribute for property getters in
protocol interfaces.
* The generator now emits the DelegateProxy attribute in ProtocolMember
attributes (and the ProtocolMember attribute has been extended with
additional properties for this purpose).
* The generator now emits the BlockProxy attribute for the parameter in
property setters.
* The generator now emits the BlockProxy attribute in ProtocolMember
attributes for property setters.
* The static registrar now emits the metadata token for the
DelegateProxy.DelegateType property into the generated code so that the
DelegateProxy attribute itself isn't needed at runtime. This is required
when the dynamic registrar has been optimized away.
Fixes https://github.com/xamarin/xamarin-macios/issues/4102.
* [tests] Update MX4105 test to expect new warnings.
If the Http Client value isn't set in the csproj, we should default to `NSUrlSessionHandler` which is also what the Xamarin.iOS Analysis rules try to enforce.
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`.
As an unintended side effect of 215ab7fc1a, we
stopped reporting MT4134 errors ("Your app is using framework X, which means
you must update your Xcode") for simulator builds.
This can be either good (people's simulator builds now succeed when the
previously didn't) or bad (people's simulator builds don't always match their
device builds, since they may still get the MT4134 error for device builds).
This patch assumes we want the improved simulator builds, and adjusts the
corresponding test accordingly.
* [mtouch] Show warnings when we can't find referenced assemblies.
This would have helped track down #4235.
* Improve MT0137 warning to indicate the type of the attribute causing the warning.
It seems Cecil doesn't search next to the current assembly for any assembly
references, which means that it may fail to resolve assemblies in certain
circumstances:
Failed files
Expected: <empty>
But was:
Failed to process /work/maccore/xcode10/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/lib/mono/2.1/OpenTK.dll: Failed to resolve assembly: 'monotouch, Version=0.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'
Failed to process /work/maccore/xcode10/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/lib/mono/Xamarin.TVOS/OpenTK-1.0.dll: Failed to resolve assembly: 'Xamarin.TVOS, Version=0.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'
Failed to process /work/maccore/xcode10/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/lib/mono/Xamarin.iOS/OpenTK-1.0.dll: Failed to resolve assembly: 'Xamarin.iOS, Version=0.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'"
However, Cecil does search the current directory by default, so before loading
any assemblies, change the current directory to the directory of the assembly
we're loading.
Fixes https://github.com/xamarin/xamarin-macios/issues/4241.
* Bump to use Xcode 10 beta 1
* Update Versions.plist
* Add a dependency on Xcode 9.4.
* [msbuild] Fix build with Xcode 10 beta 1. (#4182)
Many years ago (in Xcode 7 according to code comment)
Developer/Platforms/iPhoneOS.platform/Developer/usr disappeared, and we coped
by looking at Developer/usr instead (and also the subsequent code to locate
the bin directory was based on the location of the usr directory).
Developer/Platforms/iPhoneOS.platform/Developer/usr reappeared in Xcode 10
beta 1, but it seems useless (for one it doesn't contain a bin directory), so
in order to try to keep things sane don't look for this directory in Xcode 10
and instead go directly for Developer/usr (which is what we've been using as
the usr directory for years anyway).
Fixes this problem when building apps with Xcode 10 beta 1:
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets(626,3): error : Could not locate SDK bin directory [/Users/rolf/Projects/TestApp/test-app.csproj]
* [runtime] Build 32-bit mac executables using Xcode 9.4.
* [mtouch] Work around broken tvOS headers in Xcode 10 beta 1.
* [mtouch] Work around build problem with Apple's simd headers in Objective-C++ mode.
* Use version-agnostic paths to sdk directories.
* [tests][xtro] Add todo files (from unclassified) and adjust ignore files to avoid errors
* [macos][security] Re-enable SSL[Get|Set]AlpnProtocols. Fixes#4001 (#4022)
* [macos][security] Re-enable SSL[Get}Set]AlpnProtocols. Fixes#4001
This was fixed in macOS 10.13.4
https://github.com/xamarin/xamarin-macios/issues/4001
* [tests][monotouch-tests] Disable a few test cases (one crasher, other failures). Causes to be verified later
* [xharness] Fix permission dialog suppression in Xcode 10.
* [xharness] Ignore 32-bit macOS tests by default.
* [tests] Execute mmp regression tests with Xcode 9.4 since many of them are 32-bit and needs porting to 64-bit.
* [mmptest] Ignore 32-bit XM tests if we don't have a 32-bit-capable Xcode.
* [registrar] Add workaround for broken headers in Xcode 10 beta 1 (radar 40824697).
* [mtouch] Restrict another workaround for an Xcode 10 beta 1 bug to a specific Xcode version to remove it asap.
* [tests] Fix some protocol changes (public or not) find by introspection tests
* [tests][intro] Fix DefaultCtorAllowed failures
* [Intents] Obsolete several Intents classes in watchOS.
Several existing Intents classes have been marked as unavailable in watchOS in
the headers in Xcode 10 beta 1, and corresponding tests are now failing.
So obsolete the managed wrapper types, and fix tests accordingly.
* Fix xtro wrt previous Ietents/intro changes
* [tests] Minor adjustments to mtouch tests to work with Xcode 10.
* [msbuild] Update tests to cope with additional files produced by the Core ML compiler.
* [msbuild] Xcode 10 doesn't support building watchOS 1 apps, so show a clear error message explaining it.
Also update tests accordingly.
* [coreimage] Stub new filters and exclude ?removed? ones from tests
* Update GameplayKit and SpriteKit NSSecureCoding _upgrade_ and fix other non-public cases (in tests)
* [tests] Ignore some GameKit selectors that don't respond anymore (but seems to be available, at least in header files)
* [tests] Fix intro 32bits testing for filters resutls
* [msbuild] Slightly change error message to be better English.
- And map xbuild properties to msbuild ones for fallback paths
`XBUILD_FRAMEWORK_FOLDERS_PATH -> TargetFrameworkFallbackSearchPaths`
`MSBuildExtensionsPath -> MSBuildExtensionsPathFallbackPathsOverride`
Note:
Earlier with xbuild, the order of lookup for (example)
`MSBuildExtensionsPath` was:
1. The value of $(MSBuildExtensionsPath), which we were setting to
the in-tree path
2. /Library/Frameworks/Mono.framework/External/xbuild on osx
3. $prefix/lib/mono/xbuild (default location)
And with the above changes, it will be:
1. The value of $(MSBuildExtensionsPath), which we are no longer
setting, so the default path : $prefix/lib/mono/xbuild
2. The in-tree path, via $(MSBuildExtensionsPathFallbackPathsOverride)
3. /Library/Frameworks/Mono.framework/External/xbuild on osx
Since, XI/XM targets are used via fallback path
`/Library/Frameworks/Mono.framework/External/xbuild`, the default
location doesn't matter. And the order of the remaining two remains the
same.
The same thing applies to the target frameworks also.
watchOS extensions are top-level containers in our build (because we ignore
watchOS apps entirely in mtouch), so treat them as such when computing the
protocol member map.
Fixes issue https://github.com/xamarin/xamarin-macios/issues/3930.
watchOS extensions are top-level containers in our build (because we ignore
watchOS apps entirely in mtouch), so treat them as such when computing the
protocol member map.
Fixes issue https://github.com/xamarin/xamarin-macios/issues/3930.
Fixes this test failure:
1) Failed : Xamarin.Registrar.MT4134
errors
Expected: 9
But was: 10
This was not detected by the PR bot because this test requires having Xcode
8.3 installed (otherwise the test is ignored), and the PR bot didn't have that
version of Xcode.
The tests should be identical, except for the MT4134 test, which I've updated
to use Xcode 8.3 (and iOS 10.3) instead of Xcode 6 (and iOS 8.0). It also
needed a few other improvements to not run into other errors before the MT4134
error the test is trying to test.
If a class implements a protocol with optional members, and that class also exports methods whose selectors match an optional member, but the signature doesn't match, we must show a useful warning instead of erroring out due to a NullReferenceException.
Fixes this:
System.NullReferenceException: Object reference not set to an instance of an object
at Registrar.StaticRegistrar.GetBlockProxyAttributeMethod (Mono.Cecil.MethodDefinition method, System.Int32 parameter) [0x00001] in /Users/builder/data/lanes/1381/9de35b83/source/xamarin-macios/tools/common/StaticRegistrar.cs:4113
at Registrar.StaticRegistrar.GetBlockWrapperCreator (Registrar.Registrar+ObjCMethod obj_method, System.Int32 parameter) [0x001e1] in /Users/builder/data/lanes/1381/9de35b83/source/xamarin-macios/tools/common/StaticRegistrar.cs:4101
at Registrar.StaticRegistrar.Specialize (Registrar.AutoIndentStringBuilder sb, Registrar.Registrar+ObjCMethod method, System.Collections.Generic.List`1[T] exceptions) [0x0216b] in /Users/builder/data/lanes/1381/9de35b83/source/xamarin-macios/tools/common/StaticRegistrar.cs:3683
when building the msbuild/tests/MyWatchKit2IntentsExtension project.
If a class implements a protocol with optional members, and that class also exports methods whose selectors match an optional member, but the signature doesn't match, we must show a useful warning instead of erroring out due to a NullReferenceException.
Fixes this:
System.NullReferenceException: Object reference not set to an instance of an object
at Registrar.StaticRegistrar.GetBlockProxyAttributeMethod (Mono.Cecil.MethodDefinition method, System.Int32 parameter) [0x00001] in /Users/builder/data/lanes/1381/9de35b83/source/xamarin-macios/tools/common/StaticRegistrar.cs:4113
at Registrar.StaticRegistrar.GetBlockWrapperCreator (Registrar.Registrar+ObjCMethod obj_method, System.Int32 parameter) [0x001e1] in /Users/builder/data/lanes/1381/9de35b83/source/xamarin-macios/tools/common/StaticRegistrar.cs:4101
at Registrar.StaticRegistrar.Specialize (Registrar.AutoIndentStringBuilder sb, Registrar.Registrar+ObjCMethod method, System.Collections.Generic.List`1[T] exceptions) [0x0216b] in /Users/builder/data/lanes/1381/9de35b83/source/xamarin-macios/tools/common/StaticRegistrar.cs:3683
when building the msbuild/tests/MyWatchKit2IntentsExtension project.
This fixes a startup crash in code shared app extensions due to having the
wrong value set in the runtime (the dynamic registrar was removed, but the
executable didn't know it).
* [static registrar] Optimize creation of delegates for blocks.
Optimize creation of delegates for blocks so that it doesn't require the
dynamic registrar.
This is done by getting the metadata token for the Create method that creates
the delegate, and embed that metadata token in the generated code from the
static registrar.
Also add tests, since this scenario was not covered by tests already.
* [mmptest] Fix test after recent changes.
* [test-libraries] Avoid duplicate symbols.
* [tests] Update according to changes.
- 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
* [static registrar] Optimize creation of delegates for blocks.
Optimize creation of delegates for blocks so that it doesn't require the
dynamic registrar.
This is done by getting the metadata token for the Create method that creates
the delegate, and embed that metadata token in the generated code from the
static registrar.
Also add tests, since this scenario was not covered by tests already.
* [mmptest] Fix test after recent changes.
* [test-libraries] Avoid duplicate symbols.
* [tests] Update according to changes.
Assemblies that satisfy all of these conditions:
* Are not in the container project.
* Are in multiple app extensions.
can (and should) be bundled in the container app.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=58873
- 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
This fixes a startup crash in code shared app extensions due to having the
wrong value set in the runtime (the dynamic registrar was removed, but the
executable didn't know it).
When code sharing is enabled, only the container app/target will have a
LinkContext.
So make sure the static registrar finds that link context when it needs
information from the linker.
https://github.com/xamarin/xamarin-macios/issues/3514
When code sharing is enabled, only the container app/target will have a
LinkContext.
So make sure the static registrar finds that link context when it needs
information from the linker.
https://github.com/xamarin/xamarin-macios/issues/3514
Alexander Köplinger
Rolf Bjarne Kvinge
Vincent Dondain
Sebastien Pouliot
Manuel de la Pena
Alex Soto
Marek Safar
Ankit Jain
Ludovic Henry
Martin Baulig
Jo Shields
Chris Hamons