* [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.
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).
We want to avoid separate `mscorlib.dll` assemblies for 32/64 bits so
the architecture specific code for `n[u]int` and `nfloat` must be
preserved in both cases.
Because a single, slightly larger, assembly is much smaller than two
(slightly smaller) ones.
This is not a common situation since the extraneous preserved API are
often used in the application (or 3rd party code) so, in most cases,
a single `mscorlib.dll` was already used.
This merely close the gap for some cases, like our `link all` application
where this happened.
The linker might remove interfaces that have already been linked away. Make
sure to look for the TypeDefinition for such interfaces among the types that
have already been linked away.
Fixes https://github.com/xamarin/xamarin-macios/issues/3513.
Fixes this test:
Xamarin.ApiTest.ApiTest.AlwaysOptimizable(iOS) : All methods calling optimizable API must be optimizable
The method System.IntPtr ObjCRuntime.BlockLiteral::GetBlockForDelegate(System.Reflection.MethodInfo,System.Object,System.String) calls System.Boolean ObjCRuntime.Runtime::get_DynamicRegistrationSupported(), but it does not have a [BindingImpl (BindingImplOptions.Optimizable)] attribute.
Also skip the BlockLiteral.SetupBlock optimization for this method, because
it's not optimizable (and thus produces a warning users can't ignore).
It seems LLVM freaks out if it finds unreachable exception handlers:
* Assertion at ../../../../external/mono/mono/mini/mini-llvm.c:7406, condition `err == 0' not met
Basic Block in function 'Xamarin_iOS_ObjCRuntime_Class_GetClassHandle_System_Type' does not have terminator!
label %BB7_CALL_HANDLER_TARGET
Add a 'register-protocols' optimization that:
Improves static registrar to:
* Generate a new table of protocol -> managed wrapper type. This is required
to find the wrapper type without having the `[Protocol]` attribute around.
* Make the generated code implement protocols from [Adopts] attributes. This
makes it possible to link away the `[Protocol]` attribute, because the
native implementation of `conformsToProtocol:` does the right thing (we
might even be able to link away our complete `ConformsToProtocol` logic when
we remove the dynamic registrar).
Improves linker to:
* Not mark protocol interfaces by the mere virtue of having a type that
implements them. This is implemented by not marking protocol interfaces when
they're implementing a class, but instead when a method implementation is
found to implement a method from a protocol interface.
* Mark the wrapper type for protocols (this allows us to remove the Protocol
attribute, since that's the link between the protocol and its wrapper type).
* Remove the [Protocol], [ProtocolMember] and [Adopts] attributes (but only if
optimizing protocols).
The static registrar still needs some of the information linked away, so a few
changes are required to make it available post linker.
Benchmark
---------
I've compared the size of entire apps built for device:
|test | Before | After | Diff | % |
|:-----------------------------|-------:|-------:|-------:|------:|
|[monotouch-test/Debug][1] | 101mb | 100mb | -888kb | -0.9% |
|[monotouch-test/Release][2] | 99.2mb | 95.4mb | -830kb | -0.9% |
|[minimalistic app/Debug][3] | 10.8mb | 10.4mb | -443kb | -4.1% |
|[minimalistic app/Release][4] | 4.7mb | 4.55mb | -157kb | -3.3% |
[1]: https://gist.github.com/rolfbjarne/0181ab8abe436c34cf4ee68ecfb8cd18#monotouch-test-debug
[2]: https://gist.github.com/rolfbjarne/0181ab8abe436c34cf4ee68ecfb8cd18#monotouch-test-release
[3]: https://gist.github.com/rolfbjarne/0181ab8abe436c34cf4ee68ecfb8cd18#minimal-xi-app-debug
[4]: https://gist.github.com/rolfbjarne/0181ab8abe436c34cf4ee68ecfb8cd18#minimal-xi-app-release
Improved linker to:
* Not mark protocol interfaces by the mere virtue of having a type that
implements them. This is implemented by not marking protocol interfaces when
they're implementing a class, but instead when a method implementation is
found to implement a method from a protocol interface.
* Mark the wrapper type for protocols (this allows us to remove the Protocol
attribute, since that's the link between the protocol and its wrapper type).
* Remove the [Protocol], [ProtocolMember] and [Adopts] attributes.
The static registrar still needs some of the information linked away, so a few
changes are required to make it available post linker.
* [linker] Optimize calls to BlockLiteral.SetupBlock to inject the block signature.
Optimize calls to BlockLiteral.SetupBlock[Unsafe] to calculate the block
signature at build time, and inject it into the call site.
This makes block invocations 10-15x faster (I've added tests that asserts at
least an 8x increase).
It's also required in order to be able to remove the dynamic registrar code in
the future (since calculating the block signature at runtime requires the
dynamic registrar).
* [mtouch/mmp] Add support for reporting errors/warnings that point to the code line causing the error/warning.
Add support for reporting errors/warnings that point to the code line causing
the error/warning by adding ErrorHelper overloads that take the exact
instruction to report (previously we defaulted to the first line/instruction
in a method).
* [tests] Add support for asserting filename/linenumber in warning messages.
* Make all methods that manually create BlockLiterals optimizable.
* [tests] Create a BaseOptimizeGeneratedCodeTest test that's included in both XI's and XM's link all test.
* [tests] Add link all test (for both XI and XM) to test the BlockLiteral.SetupBlock optimization.
* [tests] Add mtouch/mmp tests for the BlockLiteral.SetupBlock optimization.
* [tests][linker] Make the base test class abstract, so tests in the base class aren't executed twice.
* [tests][linker] Don't execute linkall-only tests in linksdk.
The optimization tests only apply when the test assembly is linked, and that
only happens in linkall, so exclude those tests in linksdk.
* [tests][mmptest] Update test according to mmp changes.
Fixes these test failures:
1) Failed : Xamarin.MMP.Tests.MMPTests.MM0132("inline-runtime-arch")
The warning 'MM0132: Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.' was not found in the output:
Message #1 did not match:
actual: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.'
expected: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.'
Message #2 did not match:
actual: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.'
expected: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.'
2) Failed : Xamarin.MMP.Tests.MMPTests.MM0132("foo")
The warning 'MM0132: Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.' was not found in the output:
Message #1 did not match:
actual: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.'
expected: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.'
Message #2 did not match:
actual: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.'
expected: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.'
* [tests][linker] Fix typo.
Fixes this test failure:
1) SetupBlock_CustomDelegate (Linker.Shared.BaseOptimizeGeneratedCodeTest.SetupBlock_CustomDelegate)
Counter
Expected: 1
But was: 2
* [registrar] Minor adjustment to error message to match previous (and better) behavior.
Fixes this test failure:
1) Failed : Xamarin.Registrar.GenericType_WithInvalidParameterTypes
The error 'MT4136: The registrar cannot marshal the parameter type 'System.Collections.Generic.List`1<U>' of the parameter 'arg' in the method 'Open`1.Bar(System.Collections.Generic.List`1<U>)'' was not found in the output:
Message #1 did not match:
actual: 'The registrar cannot marshal the parameter type 'System.Collections.Generic.List`1<Foundation.NSObject>' of the parameter 'arg' in the method 'Open`1.Bar(System.Collections.Generic.List`1<U>)''
expected: 'The registrar cannot marshal the parameter type 'System.Collections.Generic.List`1<U>' of the parameter 'arg' in the method 'Open`1.Bar(System.Collections.Generic.List`1<U>)''
* [docs] mmp shows MM errors/warnings.
* [docs] Improve according to reviews.
* [tests] Fix merge failure causing test duplication.
Moving to reference sources added a few, new converters so the existing
logic to preserve them was not complete.
This update the list of converters, sorted like the reference sources
(RS) for easier reviews.
It also adds:
* a canary test in "dont link" that will fail it the RS code change
or is replaced;
* more complete unit tests to ensure all cases works
https://github.com/xamarin/xamarin-macios/issues/3372
You were the preprocessor we wished C# had natively
Removing PMCS requires these changes:
* Remove XamCore from src/
* Remove XamCore from tools/
* Remove XamCore from runtime/
* nint/nuint enum conversion
* _compat_ enum conversion
* NSAction conversion
* Hand fix single API incorrectly converted by PMCS to unbreak compatibility
- Due to a bug in PMCS, the nuint was incorrectly converted in this API.
- However, as that ship as sailed, we must "fix" it until XAMCORE_4_0
* Update readme
* Bump macios-binaries
* [ObjCRuntime] Add a BindingImplAttribute.
* [linker] Make ProviderToString an extension method on ICustomAttributeProvider to make it more discoverable.
* [generator] Use [BindingImpl] instead of [CompilerGenerated].
The entire diff is big (89MB), so it can't be gisted. However, most of it is
either removal of `using System.Runtime.CompilerServices;` or the change from
`[CompilerGenerated]` to `[BindingImpl (...)]` like this:
https://gist.github.com/rolfbjarne/8bfda3ed37b956d0342a1c1e9b079244
If I remove those parts of the diff, there's nothing significant left:
https://gist.github.com/rolfbjarne/4156164d6bdb1376366200394eb8a091
* [linker] Teach the linker about the new [BindingImpl] attribute.
In addition to the existing logic where the linker would optimize some
[CompilerGenerated] code (sometimes with additional requirements), it will now
also optimize all [BindingImpl (Optimizable)] code (without any additional
requirements).
* [tests] Add tests to make sure [BindingImpl (Optimizable)] works as expected.
* [linker] Check for [BindingImpl] before [CompilerGenerated] and stop checking for [CompilerGenerated] in XAMCORE_4_0.
Check for [BindingImpl] before checking for [CompilerGenerated], since the
former is more common.
Also stop checking for [CompilerGenerated] (at least to mean that code is
optimizable) in our next non-compatible evolutionary leap (XAMCORE_4_0):
* [introspection] Impl a better typo check.
* [linker] Implement a generic method of storing attributes that may be removed by the linker.
Implement a generic method of storing attributes that may be removed by the
linker, so that those attributes can be accessed after the linker has linked
them away.
* [linker] Store availability attributes using the new generic location.
* [linker] Store the CompilerGenerated attribute using the new generic location.
* [mtouch/mmp] Give users more control over optimizations, and share more code between mtouch and mmp.
1. Add an --optimize flag to mtouch/mmp that allows users to select which
optimizations to apply (or not). This makes it easier to add future
optimizations, and allow users to disable any optimization that causes
problems without having to disable many other features.
2. Share as much optimization code as possible between mtouch and mmp. This
immediately gives a benefit to mmp, which has three new optimizations only
mtouch had: NSObject.IsDirectBinding inlining, IntPtr.Size inlining and
dead code elimination.
This results in ~6kb of disk space saved for a linked Xamarin.Mac app:
* link sdk: [Debug][1], [Release][2]
* link all: [Debug][3], [Release][4]
Testing also verifies that monotouchtest ([Debug][5], [Release][6]) has not
changed size at all, which means that no default optimizations have changed
inadvertedly.
[1]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#link-sdk-mac--debug
[2]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#link-sdk-mac--release
[3]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#link-all-mac--debug
[4]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#link-all-mac--release
[5]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#monotouchtest-iphonedebug64
[6]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#monotouchtest-iphonerelease64
* [tools] Don't enable the IsDirectBinding optimization by default for Xamarin.Mac apps, it's not safe.
* Fix whitespace issues.
* [doc] Document optimizations.
* Officially support optimizations by adding them to the Versions.plist.
* [linker] Improve IntPtr.Size inliner + dead code eliminatior and add tests.
* Properly handle operands for the ldc_i4_s instruction (they're sbyte).
* Fix less-than condition to actually do a less-than comparison.
* Make sure to look up the bitness in the Target, not the Application, since
the Application's value will be incorrect when building fat apps (both
Is32Build and Is64Build will be true).
* Remove unnecessary checks for the IntPtr.Size inliner: this optimization
does not depend on other instructions than the IntPtr.get_Size call, so
remove the checks that verify surrounding instructions. This makes the
IntPtr.Size inliner kick in in more scenarios (such as the new tests).
* Add tests.
* [tests] Add mmp tests for optimizations.
* [tests] Fix XM optimization tests.
* [tests] Fix test build error.
Caching the result of checking whether a type is a CIFilter or not in a
dictionary makes the total time spent in the method go down to approximately a
third (11ms to 3ms) when linking monotouch-test on my machine.
Previous behavior
=================
* The linker would determine if a class is a generated binding class or not.
This was determined by the presence of a constructor taking a single IntPtr
argument, and with a [CompilerGenerated] attribute.
* If a class was not a generated binding class, then that class and all its
superclasses were marked as not optimizable (in the context of inlining the
IsDirectBinding check).
* The end result was that all classes with a [CompilerGenerated] IntPtr
constructor that weren't subclassed, were optimized (the IsDirectBinding
value was implied to be 'true').
Unfortunately this does not match how the IsDirectBinding value is actually
computed, and is in many cases quite wrong.
Background
==========
The authorative value for the IsDirectBinding value is the register attribute:
```csharp
[Register ("MyClass", true)] // the second parameter specifies the IsDirectBinding value
class MyClass : NSObject {}
```
Due to history this second parameter is called `IsWrapper` and not
`IsDirectBinding`, but it's the exact same thing.
Unfortunately looking up this attribute every time a class is instantiated is
slow (since fetching attributes is slow), so we guess this value in NSObject's
initialization: if the actual type of the object is in the platform assembly,
then we assume IsDirectBinding=true:
```csharp
IsDirectBinding = (this.GetType ().Assembly == PlatformAssembly);
```
and any subclasses in the platform assembly which is not a direct binding have
to set the correct value in their constructors.
New behavior
============
In the linker we now track three states for the IsDirectBinding value for each
class: if it can be inlined into a constant true or false, or if it has to be
checked at runtime (a nullable bool is used, and null corresponds with this
last undetermined state).
* The linker will look at the `[Register]` attribute for a class, and:
* If the type is CIFilter, store that IsDirectBinding=undetermined.
* If IsWrapper=False, store that IsDirectBinding=False for that class, and
that IsDirectBinding=undetermined for all super classes where
IsWrapper=True.
* If IsWrapper=True, tentatively assume IsDirectBinding=True in that class
unless already determined to be undetermined (which will be overruled if
a non-wrapper subclass is found later).
Results
=======
For monotouch-test, the changes are as follows:
* Classes we can now assume IsDirectBinding=true: https://gist.github.com/rolfbjarne/acd6a8cf1236562a832d6db9400afee9#file-foo-diff-L1-L25
* Classes we previously assumed incorrectly that IsDirectBinding=true: https://gist.github.com/rolfbjarne/acd6a8cf1236562a832d6db9400afee9#file-foo-diff-L27-L645
* Classes we can now assume IsDirectBinding=false: https://gist.github.com/rolfbjarne/acd6a8cf1236562a832d6db9400afee9#file-foo-diff-L647-L2281
There are also minor size improvements (in the iPhone/Debug64 configuration):
The executable is 17.632 bytes smaller:
-rwxr-xr-x 1 rolf staff 73038384 Jan 12 12:40 /Users/rolf/test/old/monotouchtest.app/monotouchtest
-rwxr-xr-x 1 rolf staff 73020752 Jan 12 12:50 /Users/rolf/test/new/monotouchtest.app/monotouchtest
Xamarin.iOS.dll is 3.072 bytes smaller (this will probably be 0 on a release (stripped) build).
-rw-r--r-- 1 rolf staff 2522624 Jan 12 12:40 /Users/rolf/test/old/monotouchtest.app/Xamarin.iOS.dll
-rw-r--r-- 1 rolf staff 2519552 Jan 12 12:50 /Users/rolf/test/new/monotouchtest.app/Xamarin.iOS.dll
CIFilter
========
There's a complication with CIFilters [1] [2], their implementation is
somewhat special, so we do not want to optimize anything for those classes to
not risk getting anything wrong.
[1] https://github.com/xamarin/xamarin-macios/pull/3055
[2] https://bugzilla.xamarin.com/show_bug.cgi?id=15465
* [linker] Refactor and simplify code optimizations.
We had several types of code optimizations, where we'd determine a particular
expression is a constant, then remove the condition and the code for any
dead branches.
Unfortunately each type of expression had its own logic to determine the
sequence of code to remove, each slightly different depending on the actual
conditional expression. This has led to bugs in the past, either when
switching between compilers (mcs/csc), or compilers have changed their emitted
code.
So implement a more generic version where each optimization just changes the
specific condition to a constant value, and then at the end we have a dead-
code-elimination pass that eliminates dead code based on those constant
conditions.
This version is also a lot more defensive than the previous code, it will bail
out without doing anything if it finds a code sequence it doesn't understand.
This also makes it easier to implement other similar code optimizations.
Simple time measuring shows no slowdown in the linker, and the size difference for monotouch-test is negligable at best:
256 bytes more for the exectuable:
-rwxr-xr-x 1 rolf staff 72890464 Dec 1 14:39 /Users/rolf/test/old/monotouchtest.app/monotouchtest
-rwxr-xr-x 1 rolf staff 72890720 Dec 1 14:44 /Users/rolf/test/new/monotouchtest.app/monotouchtest
3584 bytes less for Xamarin.iOS.dll:
-rw-r--r-- 1 rolf staff 2506240 Dec 1 14:39 /Users/rolf/test/old/monotouchtest.app/Xamarin.iOS.dll
-rw-r--r-- 1 rolf staff 2502656 Dec 1 14:44 /Users/rolf/test/new/monotouchtest.app/Xamarin.iOS.dll
I don't know why the executable grew slightly, the IL diff for Xamarin.iOS.dll
shows nothing out of the ordinary:
https://gist.github.com/rolfbjarne/33590ad651a21f9a9352ac9b97b9dc06
* [linker] NewRefcount is constantly true for Unified, so trying to inline it is useless.
* [linker] Remove redundant code.
* [linker] Remove nops at the end of methods.
It's not legal IL to have a nop as the last instruction of a method, peverify complains:
> [IL]: Error: [D:\Documentos\Rolf\Xamarin\Xamarin.iOS.dll : AVFoundation.AVAssetImageGenerator::get_AppliesPreferredTrackTransform][offset 0x0000001E] fall through end of the method without returning
so detect and remove nops at the end of methods.
Also add a sanity check to ensure we don't remove nops that are targets for
branch instructions (should never happen, but it doesn't hurt to be safe).
PEVerify shows much fewer errors now, [1721][1] vs [2581][2], although the [IL diff][3]
is bigger (due to the removed nops).
Updated timing measurements show no slowdown in the linker, and the size
difference for monotouch-test is negligable:
32 bytes less for the exectuable:
-rwxr-xr-x 1 rolf staff 72890880 Jan 12 00:54:49 2018 /Users/rolf/test/old/monotouchtest.app/monotouchtest*
-rwxr-xr-x 1 rolf staff 72890848 Jan 12 00:56:57 2018 /Users/rolf/test/new/monotouchtest.app/monotouchtest*
12288 bytes less for Xamarin.iOS.dll (this is a debug build, a release build
would probably not show any difference at all):
-rw-r--r-- 1 rolf staff 2506240 Jan 12 00:54:49 2018 /Users/rolf/test/old/monotouchtest.app/Xamarin.iOS.dll
-rw-r--r-- 1 rolf staff 2493952 Jan 12 00:56:57 2018 /Users/rolf/test/new/monotouchtest.app/Xamarin.iOS.dll
[1]: https://gist.github.com/rolfbjarne/9c8fa519a6f8e1718b125472f05ded07#file-peverify-new-txt-L1726
[2]: https://gist.github.com/rolfbjarne/9c8fa519a6f8e1718b125472f05ded07#file-peverify-old-txt-L2586
[3]: https://gist.github.com/rolfbjarne/35d5bfec1809ad2a80a7781cebe5b574
* [MetalPerformanceShaders] Activate bindings for Xamarin.Mac and add n… (#2816)
* [MetalPerformaceShaders] Several MPSCnnKernel properties should be readonly (#2938)
The subclasses versions of the properties need Override, cannot be removed since it would break visibility for iOS 10
* Remove some [Model] attributes that sholdn't be needed
* Fix introspection test crashes
* More introspection fixes
* NN does not need to be PascalCased
Remove unneeded Models and BaseTypes
* PR Whitespace fixes and renamings
* Paste fail
* More fixes from PR comments
* [MPS] Adds new intro test, fixes ctors and xtro output
* Removes duplicated availability attributes.
* Removes obsoleted API from macOS since mps is new to it.
* Fixes xtro output.
* Adds missing API.
* Fixes parameterless ctors, some of them do not really work, found
by our new intro test and disabled the one that seem to not make
sense due to the presence of DesignatedInitializers.
* Fixes a selector typo.
* Adds new `ShouldNotExposeDefaultCtorTest` to intro.
ShouldNotExposeDefaultCtorTest
==============================
This test checks for types with a parameterless ctor that are subclasses
of `NSObject` and then cheks if the BaseType of said objects also expose
a parameterless ctor (all in .NET land), if this is not the case it reports
them and so they can manually audited. Also this test has the ability to
print alloc/init ObjC code by setting `genObjCTestCode` to `true` so you can
take this code into an Xcode project and easily tests the ctors.
It seems that xtro (sharpie) does not have a complete picture of when a ctor
must be exposed hence the hability to generate this code and manually test.
Right now this test is just enabled for MPS since it is the scope of this PR.
In the future it should be enabled for all other frameworks and the output be
manually audited.
* [MPS] Fixes premature collection possible in bindings (bug 59547) and implements feedback.
https://bugzilla.xamarin.com/show_bug.cgi?id=59547
* Fixes premature collection possible in bindings im MPSKernel.cs
* Fixes MPSImageHistogramTest from using deprecated API.
* Removes renamed selectors and typos from ApiSelectorTest and ApiTypoTest.
* [MPS] Reenable Copy API and DesignatedInitializer xtro feedback
* Implement more feedback
* More feedback
Don't assume that a marked method has a caller, since a method can be marked
from XML as well.
This fixes a NullReferenceException:
> error : Could not link assemblies.
> Type: `System.Reflection.RuntimeParameterInfo`
> Assembly: `mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e`
> Reason: Object reference not set to an instance of an object
> --- inner exception
> System.NullReferenceException: Object reference not set to an instance of an object (Aufgaben-ID: 165)
> at MonoTouch.Tuner.MonoTouchMarkStep.MarkMethod (Mono.Cecil.MethodReference reference) [0x0004f] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/tools/linker/MonoTouch.Tuner/MonoTouchMarkStep.cs:105
> at Mono.Linker.Steps.MarkStep.MarkMethodCollection (System.Collections.IEnumerable methods) [0x00017] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/external/linker/linker/Mono.Linker.Steps/MarkStep.cs:1163
> at Mono.Linker.Steps.MarkStep.MarkMethods (Mono.Cecil.TypeDefinition type) [0x0000b] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/external/linker/linker/Mono.Linker.Steps/MarkStep.cs:1157
> at Xamarin.Linker.Steps.MobileMarkStep.MarkMethods (Mono.Cecil.TypeDefinition type) [0x0000b] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/tools/linker/MobileMarkStep.cs:123
> at Mono.Linker.Steps.MarkStep.ApplyPreserveInfo (Mono.Cecil.TypeDefinition type) [0x0004a] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/external/linker/linker/Mono.Linker.Steps/MarkStep.cs:1102
> at Mono.Linker.Steps.MarkStep.MarkType (Mono.Cecil.TypeReference reference) [0x001ee] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/external/linker/linker/Mono.Linker.Steps/MarkStep.cs:607
> at Xamarin.Linker.Steps.MobileMarkStep.MarkType (Mono.Cecil.TypeReference reference) [0x00001] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/tools/linker/MobileMarkStep.cs:71
> at Xamarin.Linker.Steps.CoreMarkStep.MarkType (Mono.Cecil.TypeReference reference) [0x00046] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/tools/linker/CoreMarkStep.cs:156
> at MonoTouch.Tuner.MonoTouchMarkStep.MarkType (Mono.Cecil.TypeReference reference) [0x00001] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/tools/linker/MonoTouch.Tuner/MonoTouchMarkStep.cs:84
> at Mono.Linker.Steps.MarkStep.MarkType (Mono.Cecil.TypeReference reference) [0x0007d] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/external/linker/linker/Mono.Linker.Steps/MarkStep.cs:566
> at Xamarin.Linker.Steps.MobileMarkStep.MarkType (Mono.Cecil.TypeReference reference) [0x00001] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/tools/linker/MobileMarkStep.cs:71
> at Xamarin.Linker.Steps.CoreMarkStep.MarkType (Mono.Cecil.TypeReference reference) [0x00046] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/tools/linker/CoreMarkStep.cs:156
> at MonoTouch.Tuner.MonoTouchMarkStep.MarkType (Mono.Cecil.TypeReference reference) [0x00001] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/tools/linker/MonoTouch.Tuner/MonoTouchMarkStep.cs:84
> at Mono.Linker.Steps.MarkStep.InitializeType (Mono.Cecil.TypeDefinition type) [0x0005b] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/external/linker/linker/Mono.Linker.Steps/MarkStep.cs:94
> at Mono.Linker.Steps.MarkStep.InitializeAssembly (Mono.Cecil.AssemblyDefinition assembly) [0x00025] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/external/linker/linker/Mono.Linker.Steps/MarkStep.cs:81
> at Mono.Linker.Steps.MarkStep.Initialize () [0x00016] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/external/linker/linker/Mono.Linker.Steps/MarkStep.cs:73
> at Mono.Linker.Steps.MarkStep.Process (Mono.Linker.LinkContext context) [0x00008] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/external/linker/linker/Mono.Linker.Steps/MarkStep.cs:66
> at Xamarin.Linker.Steps.MobileMarkStep.Process (Mono.Linker.LinkContext context) [0x00001] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/tools/linker/MobileMarkStep.cs:33
> at Xamarin.Linker.Steps.CoreMarkStep.Process (Mono.Linker.LinkContext context) [0x00017] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/tools/linker/CoreMarkStep.cs:26
> at MonoTouch.Tuner.MonoTouchMarkStep.Process (Mono.Linker.LinkContext context) [0x0001d] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/tools/linker/MonoTouch.Tuner/MonoTouchMarkStep.cs:36
> at Mono.Linker.Pipeline.Process (Mono.Linker.LinkContext context) [0x00023] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/external/linker/linker/Mono.Linker/Pipeline.cs:128
> at MonoTouch.Tuner.Linker.Process (MonoTouch.Tuner.LinkerOptions options, MonoTouch.Tuner.MonoTouchLinkContext& context, System.Collections.Generic.List`1[Mono.Cecil.AssemblyDefinition]& assemblies) [0x000e0] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/tools/mtouch/Tuning.cs:82
https://bugzilla.xamarin.com/show_bug.cgi?id=60176
The registrar requires the availability attributes to work properly, which is
non-trivial when the linker is being used, because the linker runs before the
registrar, and will remove availability attributes.
For this reason we store the availability attributes separately when the
linker removes them so that the registrar can still find them, but
unfortunately it's not enough to store the CustomAttribute instance, because
it may end up crippled: if the attribute type itself is removed by the linker,
then it's not possible to get the attribute type from the CustomAttribute
instance, because 'attribute.Constructor.DeclaringType' returns null (the
linker sets the declaring type of the constructor to null).
Solution: store the attribute type separately; now we use a Tuple of
CustomAttribute and TypeReference.
Fixes this ugly exception:
System.NullReferenceException: Object reference not set to an instance of an object
at XamCore.Registrar.Registrar.RegisterAssembly (Mono.Cecil.AssemblyDefinition assembly) [0x00146] in /work/maccore/master/xamarin-macios/src/ObjCRuntime/Registrar.cs:2316
at XamCore.Registrar.StaticRegistrar.Generate (System.Collections.Generic.IEnumerable`1[T] assemblies, System.String header_path, System.String source_path) [0x00035] in /work/maccore/master/xamarin-macios/tools/common/StaticRegistrar.cs:4197
at Xamarin.Bundler.RunRegistrarTask.Execute () [0x00001] in /work/maccore/master/xamarin-macios/tools/mtouch/BuildTasks.mtouch.cs:154
The registrar requires the availability attributes to work properly, which is
non-trivial when the linker is being used, because the linker runs before the
registrar, and will remove availability attributes.
For this reason we store the availability attributes separately when the
linker removes them so that the registrar can still find them, but
unfortunately it's not enough to store the CustomAttribute instance, because
it may end up crippled: if the attribute type itself is removed by the linker,
then it's not possible to get the attribute type from the CustomAttribute
instance, because 'attribute.Constructor.DeclaringType' returns null (the
linker sets the declaring type of the constructor to null).
Solution: store the attribute type separately; now we use a Tuple of
CustomAttribute and TypeReference.
Fixes this ugly exception:
System.NullReferenceException: Object reference not set to an instance of an object
at XamCore.Registrar.Registrar.RegisterAssembly (Mono.Cecil.AssemblyDefinition assembly) [0x00146] in /work/maccore/master/xamarin-macios/src/ObjCRuntime/Registrar.cs:2316
at XamCore.Registrar.StaticRegistrar.Generate (System.Collections.Generic.IEnumerable`1[T] assemblies, System.String header_path, System.String source_path) [0x00035] in /work/maccore/master/xamarin-macios/tools/common/StaticRegistrar.cs:4197
at Xamarin.Bundler.RunRegistrarTask.Execute () [0x00001] in /work/maccore/master/xamarin-macios/tools/mtouch/BuildTasks.mtouch.cs:154
Only apply smart enum conversion to enums, and downgrade related warnings to log messages.
This avoids spurious warnings like this:
> warning MT4124: Invalid BindAsAttribute found on 'Bindings.Test.ObjCRegistrarTest.GetBooleanArray': could not find the smart extension type System.BooleanExtensions. Please file a bug report at https://bugzilla.xamarin.com
when the BindAs attribute is valid, but just not about a smart enum in the first place.
Prevents these little gems:
> warning MT4124: Invalid BindAsAttribute found on 'Mono.Cecil.MethodReturnType': could not find the smart extension type ...
Only apply smart enum conversion to enums, and downgrade related warnings to log messages.
This avoids spurious warnings like this:
> warning MT4124: Invalid BindAsAttribute found on 'Bindings.Test.ObjCRegistrarTest.GetBooleanArray': could not find the smart extension type System.BooleanExtensions. Please file a bug report at https://bugzilla.xamarin.com
when the BindAs attribute is valid, but just not about a smart enum in the first place.
Prevents these little gems:
> warning MT4124: Invalid BindAsAttribute found on 'Mono.Cecil.MethodReturnType': could not find the smart extension type ...
* This framework was a private framework before iOS 11.
This framework was a private framework before iOS 11, yet the headers claim
many API were introduced in iOS 10.
So take account of this difference by using the private framework location in
iOS 10.3 or earlier.
Testing these API from Xcode works fine when run on an iOS 10.3 device, and
I've confirmed the IOSurface framework is loaded from the private frameworks
path on older devices (and when built using Xcode 9 and linked with the public
framework path).
* Disable code to make IOSurface work on iOS 10.
Disable the code to make IOSurface work on iOS 10, since it may be rejected by
the App Store.
This also means adjusting the availability attributes, so that the
introspection tests pass (and to document that technically these API won't
work when used with Xamarin.iOS in iOS 10).
I've filed bug #[59201][1] to keep track of this, maybe we can re-enable this later.
[1]: https://bugzilla.xamarin.com/show_bug.cgi?id=59201