Most fixes are inside Intents. Some types were not available on macOS
and marked as such, except it backfired.
* Adding `[NoMac]` on `XAMCORE_4_0` was fine
* Adding `[Obsolete]` outside `XAMCORE_4_0` was fine
* Removing the `[Mac (x,y)]` was not quite fine. It's true (since it was never on macOS) but removing it means it default to the oldest (10.9) macOS version we support. This is what the introspection tests were expecting.
Adding an `[Obsoleted (..., 10,0, ...)]` solve this.
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.
* Fix links that point to master to point to main instead.
* Implement support in the sample tester for specifying the default branch for
each sample repo.
* Fix various text / documentation to say 'main' instead of 'master.'
* Push to 'main' instead of 'master' in xamarin-macios-data.
* Fix xharness to make 'main' the special branch with regards to documentation tests as opposed to 'master'.
* Fix various CI to use 'main' instead of 'master'.
This is a backport of PR #9561
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.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
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.
backport of https://github.com/xamarin/xamarin-macios/pull/9604
reference: https://github.com/xamarin/xamarin-macios/issues/9578
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()
Remove the following warning:
```
uikit.cs(22829,21): warning CS0108: 'UIViewConfigurationState.TraitCollection' hides inherited member 'UIConfigurationState.TraitCollection'. Use the new keyword if hiding was intended.
```
Remove the following warning:
```
arkit.cs(2056,32): warning CS8632: The annotation for nullable reference types should only be used in code within a '#nullable' annotations context.
```
The following warnings are printed during the build:
```
carplay.cs(443,10): warning CS0108: 'CPListItem.Text' hides inherited member 'CPListTemplateItem.Text'. Use the new keyword if hiding was intended.
carplay.cs(456,12): warning CS0108: 'CPListItem.UserInfo' hides inherited member 'CPListTemplateItem.UserInfo'. Use the new keyword if hiding was intended.
carplay.cs(505,31): warning CS0108: 'CPListItem.Handler' hides inherited member 'CPSelectableListItem.Handler'. Use the new keyword if hiding was intended.
carplay.cs(1437,31): warning CS0108: 'CPListImageRowItem.Handler' hides inherited member 'CPSelectableListItem.Handler'. Use the new keyword if hiding was intended.
carplay.cs(1447,10): warning CS0108: 'CPListImageRowItem.Text' hides inherited member 'CPListTemplateItem.Text'. Use the new keyword if hiding was intended.
carplay.cs(1450,12): warning CS0108: 'CPListImageRowItem.UserInfo' hides inherited member 'CPListTemplateItem.UserInfo'. Use the new keyword if hiding was intended.
carplay.cs(1516,10): warning CS0108: 'CPMessageListItem.Text' hides inherited member 'CPListTemplateItem.Text'. Use the new keyword if hiding was intended.
carplay.cs(1519,12): warning CS0108: 'CPMessageListItem.UserInfo' hides inherited member 'CPListTemplateItem.UserInfo'. Use the new keyword if hiding was intended.
```
* [fileprovider] Update for Xcode 12 beta 6
This was quite noisy. Apple removed all API marked as
`FILEPROVIDER_API_AVAILABILITY_V3`.
```
```
Most were bound but they were (majority) decorated with `[NoiOS]` and
`[NoMac]` so they did not generated any bindings.
A few of them were modified or just became macOS-only.
Deprecation warnings also needed to be updated.
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