This way we know at runtime what's available and what's not, which means that
the runtime won't try to register assemblies when the dynamic registrar has
been linked away.
Fixes this startup crash in monotouch-test when all optimizations have been enabled:
Unhandled Exception:
ObjCRuntime.RuntimeException: The runtime function register_assembly has been linked away.
* [src] Build the .NET version of our product assemblies using a .NET 5 BCL.
We're not shipping the .NET product assemblies in any stable release, so we
can use a preview version of the .NET 5 BCL.
Also:
* Add all the nuget feeds we need to the top-level NuGet.config, even for .NET
5/6, there shouldn't be any conflicts with stable feeds since we use exact
version numbers.
* Generate a top-level global5.json which is copied to every directory that
needs a .NET 5 global.json (overriding the .NET 3.1 global.json in the root
directory).
* Use the expected dotnet binary during our local build.
* [tests] Fix the bgen tests to use .NET 5.
* [xharness] Set the current directory to the project directory when running .NET tests.
This way we end up using the dotnet version that's configured in global.json for the tests.
This test variation ends up being too big (1.5 GB), so it doesn't install
properly and the app crashes at startup.
So just skip it.
Fixes https://github.com/xamarin/maccore/issues/2282.
1. Assert that we got permission to CoreBluetooth before doing anything. This
makes it so that if permission has been denied, or if we're running on the
bots and permission has not been granted, these tests won't run. It does
not affect local test runs where permissions haven't been granted nor
denied.
2. Rework the code to wait for CoreBluetooth to power on in the SetUp method.
Mark the test as inconclusive if CoreBluetooth never powers on (this
happens if nobody answers the bluetooth permission dialog, quite typical
when running tests locally).
Fixes these tests when running locally on a tvOS device:
MonoTouchFixtures.CoreBluetooth.CBCentralManagerTest
[FAIL] Constructors
[FAIL] ScanForPeripherals
New APIs:
CGPoint:
public void Deconstruct(
out nfloat x,
out nfloat y)
CGSize:
public void Deconstruct(
out nfloat width,
out nfloat height)
CGRect:
public void Deconstruct(
out nfloat x,
out nfloat y,
out nfloat width,
out nfloat height)
public void Deconstruct(
out CGPoint location,
out CGSize size)
Usage:
var (location, size) = View.Frame;
var (x, y, width, height) = View.Frame;
var (x, y) = View.Frame.Location;
var (width, height) = View.Frame.Size;
Uncaught exceptions in a background thread will cause the process to crash.
Instead marshal any exceptions to the main thread, which asserts that no
exceptions were thrown.
Some .NET test projects (monotouch-test) require this to set properties for
some test variations, and .NET projects are quite minimal, making it likely
that they won't have a particular property that needs to be set/modified.
This makes it possible to execute the various monotouch-test variations for
.NET in xharness (some of the variations still fail though, so they're still
ignored by default).
Rolf nailed the issue in https://github.com/xamarin/xamarin-macios/issues/9578#issuecomment-688409802
> The problem is that iOS returns an instance of a private type (_MPMusicPlayerMediaItemProxy) which is an NSProxy subclass, and currently we don't support NSProxy.
https://github.com/rolfbjarne/xamarin-macios/commit/873a1e1 was on the
right track but it turns out `[ForcedType]` on properties don't need, nor
work (same generated code), with `return:`.
Inside `DynamicRegistrar.cs` the method
```csharp
public Type Lookup (IntPtr @class, bool throw_on_error)
```
did not respect (was unused) the `throw_on_error`. That made it
impossible to force the type to the pointer we got.
In `Runtime.cs` the method `LookupINativeObjectImplementation` must also
be able to work without an exception (from the `Lookup`) at least when we
want to force the type.
Some appextension mtouch code had to be moved to shared code. This code is currently
only used for iOS/tvOS/watchOS, but it will eventually be applicable to macOS as
well.
This makes it possible to re-use the registrar code in dotnet-linker.
Fixes these linkall tests:
Linker.Shared.OptimizeGeneratedCodeTest
[FAIL] IsARM64CallingConvention : optimized: no ldsfld instruction
Expected: 0
But was: 1
at Linker.Shared.BaseOptimizeGeneratedCodeTest.IsARM64CallingConvention() in /Users/rolf/work/maccore/main/xamarin-macios/tests/linker/BaseOptimizeGeneratedCodeTest.cs:line 527
[FAIL] SetupBlockPerfTest : At least 6x speedup
Expected: greater than 6
But was: 1.0876440665344851d
at Linker.Shared.BaseOptimizeGeneratedCodeTest.SetupBlockPerfTest() in /Users/rolf/work/maccore/main/xamarin-macios/tests/linker/BaseOptimizeGeneratedCodeTest.cs:line 120
And linkall is now green for .NET/Debug.
Calling Uri.PathAndQuery is not allowed on a relative Uri, which made the
previous Uri -> NSUrl implicit operator always throw if given a relative
NSUrl.
So I fixed that, added several tests, and found another issue (it turns out
that 'url.RelativePath == url.Path' is not a reliable way to detect absolute
urls, because it's true for relative urls as well) and fixed that too.
Fixes https://github.com/xamarin/xamarin-macios/issues/9607.
* [dotnet] Pass the Optimize flags from the extra bundler arguments to the linker configuration.
Also call Application.InitializeCommon to initialize the application instance. The
important part here is that InitializeCommon calls Optimizations.Initialize to compute
the default optimizations. It also calls Set*ExceptionMode and sets the default EnableCoopGC
value (so we don't need to call/set those anymore), and it does a few other initialization
tasks which we don't need yet, but eventually will.
And finally remember to parse the bundler arguments before using them in the dotnet
build logic. How did this not cause problems before? 🤦
* [tests] Set the verbosity using the additional args instead of an internal variable.
The internal _BundlerVerbosity variable is overwritten now (with the verbosity
value from the additional args).
* [xharness] Disable tvOS generation for the introspection/.NET test, it incorrect and needs fixing.
The type references are not cleaned (anymore?) and what's in memory can
be different from what will be saved to disk (which is the part that
matter).
So before linking we can check for type references (in a module) but
after linking need to see if it resolve (which means the definition,
of the reference, can still be found) and, just be be thorough, check
that's it's marked (if found).
Refactor the Optimizations class to have no conditionally compiled code, which makes
it re-usable from our dotnet-linker code.
Also return any errors or warnings instead of showing/throwing them, which makes
the caller able to show them using whatever means is easiest for the caller.
One test needed an update to the list of valid optimizations, because we now have
a per-platform map of valid optimizations, instead of just a iOS/tvOS/watchOS vs
macOS split ('remove-unsupported-il-for-bitcode' is only valid for watchOS, and now
we say so, while we previously said it was a valid optimization for iOS and tvOS
as well, even though we'd warn about it and do nothing if you tried to set it).
Unfortunately due to when things happen in the .NET build logic, we need to
define the DebuggerSupport property (which determines whether the app should
include debugging support or not) before importing the .NET build files. Since
we want to use the _BundlerDebug property (a.k.a. MtouchDebug/MmpDebug) to
determine if the app should include debugging support, we must figure out the
value of the _BundlerDebug property before we can define the DebuggerSupport
property. This turned out complicated, because we're currently defining
_BundlerDebug in our old-style MSBuild logic, which is imported after we
import the .NET build logic.
The end result is that we can either shuffle around a lot of MSBuild code, or
copy a few lines to set the _BundlerDebug property. Neither option makes me
very happy, but copying a few lines of code seemed the better option, so
that's what I did.
Fixes these linkall test failures in Release mode:
LinkAll.Attributes.AttributeTest
[FAIL] DebugAssemblyAttributes : DebuggableAttribute
Expected: False
But was: True
at LinkAll.Attributes.AttributeTest.DebugAssemblyAttributes()
[FAIL] DebugConstructorAttributes : No debug attribute in release mode
Expected: 0
But was: 2
at LinkAll.Attributes.AttributeTest.DebugConstructorAttributes()
[FAIL] DebugPropertyAttributes : DebuggerBrowsable
Expected: False
But was: True
at LinkAll.Attributes.AttributeTest.DebugPropertyAttributes()
[FAIL] DebugTypeAttributes : no debug attribute in release mode
Expected: 0
But was: 5
at LinkAll.Attributes.AttributeTest.DebugTypeAttributes()
[FAIL] DebuggerTypeProxy_24203 : proxy
Expected: null
But was: <System.Collections.Generic.IDictionaryDebugView`2[K,V]>
at LinkAll.Attributes.AttributeTest.DebuggerTypeProxy_24203()
Prebuild the Touch.Client projects for macOS when packaging the Xamarin.Mac
tests, so that when we try to build all the Xamarin.Mac test projects in
parallel, we don't end up trying to build the Touch.Client projects from
multiple build processes at the same time, causing numerous random failures
because all the processes are stomping on eachother.
The Assembly.IsFrameworkAssembly property is used in two places:
* In Driver.IsBoundAssembly to return early when determining if an assembly has any NSObject subclasses: c1c5b9aac6/tools/mtouch/mtouch.cs (L1155-L1168)
* In Assembly.ExtractNativeLinkInfo to return early when looking for assemblies with LinkWith attributes: c1c5b9aac6/tools/common/Assembly.cs (L150-L154)
In both cases this definition of framework assembly works today and seems likely to work in the future as well.
I also went through and looked at all the usages of Profile.IsSdkAssembly, and it's used to:
* Decide which assemblies are selected for "link sdk"
* Decide which assemblies are considered an 'sdk' assembly for creating a user framework of all the sdk assemblies
* Bail out early when deciding whether:
* An assembly references the product assembly (Xamarin.iOS.dll, etc.)
* An assembly can contain references to UIWebView
* An assembly can contain user resources
* An assembly is a binding project / has third-party native resources
* An assembly needs the dynamic registrar
* An assembly has FieldAttributes whose native fields must be preserved by the native linker
In all cases our .NET definition of 'SDK' seems to work both for now and in the future.
There are also a few usages which does not apply to .NET, so I've ignored them:
* When looking for a few BCL APIs that must be preserved (MobileApplyPreserveAttribute.cs): this is to be done in the upstream .NET linker now, so it doesn't apply to our own code
* When linking away parameter names (MonoTouchMarkStep.cs): this is to be done in the upstream .NET linker now, so it doesn't apply to our own code
Fixes these test failures:
Linker.Sealer.SealerTest
[FAIL] Final : A
Expected: True
But was: False
at Linker.Sealer.SealerTest.Final()
[FAIL] Sealed : Sealable
Expected: True
But was: False
at Linker.Sealer.SealerTest.Sealed()
[FAIL] Virtual : C
Expected: False
But was: True
at Linker.Sealer.SealerTest.Virtual()
Also ignore the BindingsAndBeforeInitField test because we're missing a few linker bits to make it work.
Fixes this linkall test failure:
LinkAll.CommonLinkAllTest
[FAIL] BindingsAndBeforeInitField : one
Expected: 1
But was: 0
at LinkAll.CommonLinkAllTest.BindingsAndBeforeInitField() in /Users/rolf/work/maccore/whatever/xamarin-macios/tests/linker/CommonLinkAllTest.cs:line 65
Fixes these test failures:
LinkAll.Layout.ClassLayoutTest
[FAIL] AutoLayoutClass : Length
Expected: 1
But was: 2
at LinkAll.Layout.ClassLayoutTest.AutoLayoutClass() in /Users/rolf/work/maccore/whatever/xamarin-macios/tests/linker/ios/link all/ClassLayoutTest.cs:line 73
[FAIL] DefaultLayoutClass : Length
Expected: 1
But was: 2
at LinkAll.Layout.ClassLayoutTest.DefaultLayoutClass() in /Users/rolf/work/maccore/whatever/xamarin-macios/tests/linker/ios/link all/ClassLayoutTest.cs:line 57
Ref: https://github.com/mono/linker/issues/1460
Fixes this test failure:
LinkAll.Serialization.DataContract.DataContractTest
[FAIL] Flags : System.NullReferenceException : Object reference not set to an instance of an object
at System.Runtime.Serialization.CodeGenerator.VerifyParameterCount(MethodInfo methodInfo, Int32 expectedCount)
at System.Runtime.Serialization.CodeGenerator.Call(Object thisObj, MethodInfo methodInfo, Object param1, Object param2)
at System.Runtime.Serialization.XmlFormatWriterGenerator.CriticalHelper.InternalSerialize(MethodInfo methodInfo, LocalBuilder memberValue, Type memberType, Boolean writeXsiType)
at System.Runtime.Serialization.XmlFormatWriterGenerator.CriticalHelper.WriteValue(LocalBuilder memberValue, Boolean writeXsiType)
at System.Runtime.Serialization.XmlFormatWriterGenerator.CriticalHelper.WriteMembers(ClassDataContract classContract, LocalBuilder extensionDataLocal, ClassDataContract derivedMostClassContract)
at System.Runtime.Serialization.XmlFormatWriterGenerator.CriticalHelper.WriteClass(ClassDataContract classContract)
at System.Runtime.Serialization.XmlFormatWriterGenerator.CriticalHelper.GenerateClassWriter(ClassDataContract classContract)
at System.Runtime.Serialization.XmlFormatWriterGenerator.GenerateClassWriter(ClassDataContract classContract)
at System.Runtime.Serialization.ClassDataContract.CreateXmlFormatWriterDelegate()
at System.Runtime.Serialization.ClassDataContract.get_XmlFormatWriterDelegate()
at System.Runtime.Serialization.ClassDataContract.WriteXmlValue(XmlWriterDelegator xmlWriter, Object obj, XmlObjectSerializerWriteContext context)
at System.Runtime.Serialization.XmlObjectSerializerWriteContext.WriteDataContractValue(DataContract dataContract, XmlWriterDelegator xmlWriter, Object obj, RuntimeTypeHandle declaredTypeHandle)
at System.Runtime.Serialization.XmlObjectSerializerWriteContext.SerializeWithoutXsiType(DataContract dataContract, XmlWriterDelegator xmlWriter, Object obj, RuntimeTypeHandle declaredTypeHandle)
at System.Runtime.Serialization.DataContractSerializer.InternalWriteObjectContent(XmlWriterDelegator writer, Object graph, DataContractResolver dataContractResolver)
at System.Runtime.Serialization.DataContractSerializer.InternalWriteObject(XmlWriterDelegator writer, Object graph, DataContractResolver dataContractResolver)
at System.Runtime.Serialization.XmlObjectSerializer.WriteObjectHandleExceptions(XmlWriterDelegator writer, Object graph, DataContractResolver dataContractResolver)
at System.Runtime.Serialization.XmlObjectSerializer.WriteObjectHandleExceptions(XmlWriterDelegator writer, Object graph)
at System.Runtime.Serialization.DataContractSerializer.WriteObject(XmlWriter writer, Object graph)
at LinkAll.Serialization.DataContract.DataContractTest.ToXml[TestClass](TestClass obj) in [...]/xamarin-macios/tests/linker/ios/link all/DataContractTest.cs:line 35
at LinkAll.Serialization.DataContract.DataContractTest.Flags() in [...]/xamarin-macios/tests/linker/ios/link all/DataContractTest.cs:line 73
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
Fixes this test failure:
LinkAll.CommonLinkAllTest
[FAIL] TypeConverter_Custom : ConverterTypeName
String lengths are both 88. Strings differ at index 43.
Expected: "...nk all, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null"
But was: "...nk all, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
------------------------------^
at LinkAll.CommonLinkAllTest.TypeConverter_Custom() in /Users/rolf/work/maccore/whatever/xamarin-macios/tests/linker/CommonLinkAllTest.cs:line 88
Rolf Bjarne Kvinge
Manuel de la Pena
Whitney Schmidt
Aaron Bockover
Sebastien Pouliot
TJ Lambert