* [registrar] Add support for specifying that a protocol changed informal status in a certain SDK. Fixes#43780
Add support for specifying that an informal protocol became a formal protocol
(or the reverse) in a certain SDK version, so that the static registrar can
generate the correct code based on the SDK being built with.
This also fixes a series of compiler warnings when using the static registrar:
In file included from Xamarin.Mac.registrar.full.i386.m:1:
./Xamarin.Mac.registrar.full.i386.h:374:11: warning: duplicate protocol definition of 'CALayerDelegate' is ignored
@protocol CALayerDelegate
^
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/QuartzCore.framework/Headers/CALayer.h:798:11: note: previous definition is here
@protocol CALayerDelegate <NSObject>
^
In file included from Xamarin.Mac.registrar.full.i386.m:1:
./Xamarin.Mac.registrar.full.i386.h:824:11: warning: duplicate protocol definition of 'WebDownloadDelegate' is ignored
@protocol WebDownloadDelegate
^
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/WebKit.framework/Headers/WebDownload.h:60:11: note: previous definition is here
@protocol WebDownloadDelegate <NSURLDownloadDelegate>
^
In file included from Xamarin.Mac.registrar.full.i386.m:1:
./Xamarin.Mac.registrar.full.i386.h:851:11: warning: duplicate protocol definition of 'WebFrameLoadDelegate' is ignored
@protocol WebFrameLoadDelegate
^
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/WebKit.framework/Headers/WebFrameLoadDelegate.h:51:11: note: previous definition is here
@protocol WebFrameLoadDelegate <NSObject>
^
In file included from Xamarin.Mac.registrar.full.i386.m:1:
./Xamarin.Mac.registrar.full.i386.h:866:11: warning: duplicate protocol definition of 'WebPolicyDelegate' is ignored
@protocol WebPolicyDelegate
^
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/WebKit.framework/Headers/WebPolicyDelegate.h:138:11: note: previous definition is here
@protocol WebPolicyDelegate <NSObject>
^
In file included from Xamarin.Mac.registrar.full.i386.m:1:
./Xamarin.Mac.registrar.full.i386.h:869:11: warning: duplicate protocol definition of 'WebResourceLoadDelegate' is ignored
@protocol WebResourceLoadDelegate
^
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/WebKit.framework/Headers/WebResourceLoadDelegate.h:46:11: note: previous definition is here
@protocol WebResourceLoadDelegate <NSObject>
^
In file included from Xamarin.Mac.registrar.full.i386.m:1:
./Xamarin.Mac.registrar.full.i386.h:872:11: warning: duplicate protocol definition of 'WebUIDelegate' is ignored
@protocol WebUIDelegate
^
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/WebKit.framework/Headers/WebUIDelegate.h:153:11: note: previous definition is here
@protocol WebUIDelegate <NSObject>
^
https://bugzilla.xamarin.com/show_bug.cgi?id=43780
* [registrar] Use a string to specify when a protocol went from informal to formal.
Use a string to specify when a protocol went from informal to formal, and
don't support the reverse condition (going from formal to informal), since
it's currently not needed and makes the code more complicated and harder to
understand.
Also add an mtouch test, and update an existing mmp test to be more restrictive.
* [registrar] Rename from 'InformalUntil' to 'FormalSince'.
It just sounds better.
The generated registrar code must be built with -DDYNAMIC_MONO_RUNTIME so that
it references our local mono functions which do a dynamic function lookup.
This fixes an issue where release builds that don't embed mono fails to link,
because there are numerous unresolved externals pointing to mono symbols.
Replace https://github.com/xamarin/xamarin-macios/pull/1973 expect that
the test parts are still needed.
* Add XM SDK + LinkSkip test
* [macos] Add platform linking support to msbuild
* [macos] Add full SDK test
* [macios] Diable classic from using linkplatform
- Extended test infrastructure change to allow classic projects that include bundling
- Setting linkplatform in MonoBundlingExtraArgs since we don't even read project setting LinkMode - Platform for classic
- Actually enable hybrid AOT by adding argument in right location
- Hybrid AOT and stripping does not play well currently with partial AOT
- Fix AOT makefile to work with nuget nunit
- https://bugzilla.xamarin.com/show_bug.cgi?id=55041
* [tests] Convert mmp tests to a standard NUnit test library.
* [xharness] Add support for restoring nugets before building projects.
And restore nugets for tests-mac.sln before building mac test projects.
Of particular importance is if we're building for LLVM or not: this fixes a
bug where we wouldn't pass --llvm to the AOT compiler when compiling
assemblies to frameworks (which we do when sharing code).
https://bugzilla.xamarin.com/show_bug.cgi?id=55555
* Use Visual Studio instead of Xamarin Studio.
* VS doesn't have mdtool, it has vstool.
Also there's no need to manually invoke the mdtool.exe executable anymore
(which we did because the mdtool executable had a min macOS version of 10.9,
and we used to build tests on older macOS versions [1]), since now we only run
tests on older macOS versions, we don't build those tests there.
[1] a1932b0ccd
- In some build cases this chunk of code:
<ItemGroup Condition=" '$(NoCompilerStandardLib)' == 'true' and '$(NoStdLib)' != 'true' ">
<!-- Note that unlike VB, C# does not automatically locate System.dll as a "standard library"
instead the reference is always passed from the project. Also, for mscorlib.dll
we need to provide the explicit location in order to maintain the correct behaviour
-->
<_ExplicitReference Include="$(FrameworkPathOverride)\mscorlib.dll" />
</ItemGroup>
would trigger and force us to use mscorlib from system mono. That does not work well.
- By setting FrameworkPathOverride, we can get the right mscorlib
- However, that ItemGroup happens outside of a target, so we must move our setting to match for it to take effect
Add an assembly registration event, that allows apps to opt out of
Xamarin.Mac's default behavior to recursively load every assembly referenced
by the entry assembly.
This is only for Xamarin.Mac, since it does not make sense to have this API in
Xamarin.iOS because assemblies are statically registered at build time.
They were thought to be macOS only but xtro corrected me, they are
new in iOS 10.3 even if some existed previously.
references (xtro):
!missing-pinvoke! SecCertificateCopyCommonName is not bound
!missing-pinvoke! SecCertificateCopyEmailAddresses is not bound
!missing-pinvoke! SecCertificateCopyNormalizedIssuerSequence is not bound
!missing-pinvoke! SecCertificateCopyNormalizedSubjectSequence is not bound
!missing-pinvoke! SecCertificateCopyPublicKey is not bound
!missing-pinvoke! SecCertificateCopySerialNumber is not bound
reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=52505
- Significant changes to target file under msbuild, ImplicitFacade processing in particular
- Tests are disabled due to https://bugzilla.xamarin.com/show_bug.cgi?id=53164 where we can't tests local target files only global
- Requires a mono msbuild with 95ab657a90 for tests to pass
- Until then, this is a workaround:
sudo cp /Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/15.0/bin/Roslyn/System.Reflection.Metadata.dll /Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/15.0/bin/
Create a custom AssemblyCollection class that contains a dictionary with
assembly identity (name) -> Assembly mapping.
This also means that we can detect if we end up loading multiple assemblies
with the same identity, and show an error in that case (even if that case
should never happen since we cache assemblies based on the identity, it's nice
to have code that ensures it).
* [tests] Use the target directory from the loaded configuration.
* [xharness] Find the root directory based on xharness.exe's location (unless specified).
* [tests] Add makefile target to generate test config using the system XI.
* [mtouch] Always require a SDK version when building.
Technically it was required before too, but the error messages were non-optimal:
it could for instance complain that the user is using an iOS framework that
was introduced in iOS 2.0.
* [mtouch tests] Rewrite MT0060 and MT0061 tests to use MTouchTool.
This makes sure we pass --sdk to mtouch (which MTouchTool does by default), so
that we don't run into MT0025 before the errors we're testing for.
* [jenkins] Add support for enabling device builds using labels.
* [xharness] Give the iOS MSBuild tests 30 minutes to finish.
* [mtouch tests] Give the BuildTestProject 10 minutes to compile each test case.
Wrench bots build the dontlink test in ~3m40, but that's apparently not enough
for the Jenkins bots (slower bots?), which time out the test after 5 minutes.
So double the timeout to 10 minutes, which will hopefully give the Jenkins
bots enough time to run the test to completion.
- https://bugzilla.xamarin.com/show_bug.cgi?id=45764
- _CompileToNative's output in msbuild was incorrectly set to:
$(_AppBundlePath)Contents\MacOS\$(TargetFileName) when the generated
file lives at $(_AppBundlePath)Contents\MonoBundle\$(TargetFileName).
- This means we'd always try to rebuild, which can be rather time consuming.
- The XI target file is just different enough to require a seperate fix.
* [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.