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 ...
Fix collecting required internal symbols which aren't in the objc_msgSend
family by not bailing out early for a function which isn't in the objc_msgSend
family.
Also add a test.
When we process P/Invokes to add support for exception marshaling, we may
change P/Invokes to be __Internal. This means that we need to move the check
for __Internal P/Invokes to after processing P/Invokes for exception
marshaling.
https://bugzilla.xamarin.com/show_bug.cgi?id=57833
* [mtouch] Improve how we make sure native symbols aren't stripped away. Fixes#51710 and #54417.
* Refactor required symbol collection to store more information about each
symbol (field, function, Objective-C class), and in general make the code
more straight forward.
* Implement support for generating source code that references these symbols,
and do this whenever we can't ask the native linker to keep these symbols
(when using bitcode). Additionally make it possible to do this manually, so
that the source code can be generated for non-bitcode platforms too (which
is useful if the number of symbols is enormous, in which case we might
surpass the maximum command-line length).
* Also make it possible to completely ignore native symbols, or ignore them on
a per-symbol basis. This provides a fallback for users if we get something
right and we try to preserve something that shouldn't be preserved (for
instance if it doesn't exist), and the user ends up with unfixable linker
errors.
* Don't collect Objective-C classes unless they're in an assembly with
LinkWith attributes. We don't need to preserve Objective-C classes in any
other circumstances.
* Implement everything for both Xamarin.iOS and Xamarin.Mac, and share the
code between them.
* Remove previous workaround for bug #51710, since it's no longer needed.
* Add tests.
https://bugzilla.xamarin.com/show_bug.cgi?id=54417https://bugzilla.xamarin.com/show_bug.cgi?id=51710
* [mtouch] Make sure to only keep symbols from the current app when code sharing.
This fixes a build problem with the interdependent-binding-projects test when
testing in Today Extension mode.
`csc` without `/optimize` generates different IL, including additional
and not required load and store instructions. We previously ignored them
but that could leave the stack unbalanced leading to runtime exceptions.
We are now nop'ing the extraneous instructions (same as the rest of the
unneeded branch code)
This fixes#53872 [1] and also the known parts of #56209 (the other parts
are still NEEDINFO and could, possibly, be unrelated).
[1] https://bugzilla.xamarin.com/show_bug.cgi?id=53872
[2] https://bugzilla.xamarin.com/show_bug.cgi?id=56209#c2
a. System.Net.Http.Primitives.dll is user code *and* contains type
forwarders (it's like a facade) to another facade assembly,
System.Net.Primitives.dll, that ships with the SDK;
b. The former, System.Net.Http.Primitives.dll, is not processed by
the linker, e.g. no code is removed and the assembly cannot be deleted.
However we save back (as much as we can [1]) the result of any type
being resolved;
c. It also means the later, System.Net.Primitives.dll, is fully linked
and (in many cases) can be removed from the final application (as it's
mostly forwarders).
d. This means the final, re-saved, System.Net.Http.Primitives.dll binary
could point to non-existing metadata, i.e. the removed
System.Net.Primitives.dll, because of [1].
Because we resolve (and save) the forwarders *and* because we do not
allow code downloads or generation (Apple restriction) it is possible to
remove the forwarders, which will fix the issue for XI.
[1] The scope of exported types cannot be updated
abb4e902da/Mono.Cecil/ExportedType.cs (L41)
There is also a enhancement bug, #11165, about this but it predated our
PCL support and the resolve-n-save that we now do for forwarders. This
is now _fully_ fixed.
References:
* https://bugzilla.xamarin.com/show_bug.cgi?id=11165 (enhancement)
* https://bugzilla.xamarin.com/show_bug.cgi?id=51805
The native linker treats object files (.o) and static libraries (.a files,
which are archives of .o files) differently.
The native linker will always include object files into the executable:
$ echo "void xxx () {}" > foo.m
$ clang -c foo.m -o foo.o -arch x86_64
$ ld foo.o -dylib -o foo.dylib -macosx_version_min 10.12 -arch x86_64
$ nm foo.dylib
0000000000000fe0 T _xxx
However, if the object file is inside a static library:
$ echo "void xxx () {}" > foo.m
$ clang -c foo.m -o foo.o -arch x86_64
$ ar cru foo.a foo.o
$ ld foo.a -dylib -o foo.dylib -macosx_version_min 10.12 -arch x86_64
$ nm foo.dylib
<no output>
This means that our testing library (libtest.a) which is a fat library of
_object files_, do not show the problems reported in bug #51548.
So:
a) I've fixed the creation of libtest.a to be a fat library of _static
libraries_. This causes the `FastDev_LinkWithTest` test to fail exactly
like in bug #51548.
b) I've made mtouch pass `-u <native symbol>` to the native linker, for every
native symbol referenced in a managed assembly, when creating a dylib.
Amazingly this seems to work fine even with symbols to Objective-C classes
(`_OBJC_CLASS_$_<class name>`).
c) This also required adding support for collecting the Objective-C names of
all managed types registered with Objective-C to the linker. The
information is already available in the static registrar, but that would
require us to make sure the static registrar is executed before compiling
dylibs, which means those two tasks won't be able to run in parallel (also
there's no guarantee we'll even run the static registrar).
https://bugzilla.xamarin.com/show_bug.cgi?id=51548
TL&DR: This is *how* it should be done and tested, it's not complete
(single, simple case) nor the most interesting case ;-)
The trick is to make sure each case is covered by tests so a mono
_bump_ won't give us a BCL that does not conform to what the linker
expect.
What's the impact ?
1. There is the expected reduction of metadata in mscorlib. Since both
methods don't call other API there's no indirect effect (removal).
--- before 2017-01-15 11:12:44.000000000 -0500
+++ after 2017-01-15 11:12:56.000000000 -0500
@@ -13166,9 +13166,6 @@
System.Void System.Security.SecurityException::.ctor(System.Runtime.Serialization.SerializationInfo,System.Runtime.Serialization.StreamingContext)
System.Void System.Security.SecurityException::.ctor(System.String)
System.Void System.Security.SecurityException::GetObjectData(System.Runtime.Serialization.SerializationInfo,System.Runtime.Serialization.StreamingContext)
-System.Boolean System.Security.SecurityManager::CheckElevatedPermissions()
-System.Security.SecurityManager
-System.Void System.Security.SecurityManager::EnsureElevatedPermissions()
System.Security.SecurityRulesAttribute
System.Security.SecurityRuleSet System.Security.SecurityRulesAttribute::m_ruleSet
System.Void System.Security.SecurityRulesAttribute::.ctor(System.Security.SecurityRuleSet)
2. There is no visible size change (even with #1) in mscorlib.dll due to
padding (compiler /filealign)
mscorlib.dll 793,600 793,600 0 0.00 %
3. there's a *very* small reduction of mscorlib.*.aotdata size
mscorlib.armv7.aotdata 717,264 717,216 -48 -0.01 %
mscorlib.arm64.aotdata 712,840 712,704 -136 -0.02 %
AOT data *.aotdata 6,460,064 6,459,880 -184 0.00 %
4. there's no change in executable size - normal as the AOT compiler has
_likely_ already doing the same optimization (before this commit)
Executable 29,270,272 29,270,272 0 0.00 %
Full comparison: https://gist.github.com/spouliot/0464c8fa3a92b6486dfd90595d9eb718
This allows mtouch to give better error message when something unexpected
occurs in the linker pipeline (at least for the sub-steps).
Practically it means fewer, contextless MT2001 errors. The replacements
error code are more precise, e.g.
* what was being done;
* what was being processed
and helps both diagnosing and, possibly, gives clues for workarounds
Right now the logic exists in a few places, both in and outside the
linker. We recently began to use part of the linker pipeline in normal /
all builds so it's easier to share (and unify) the code now.
The real gain is to avoid copying assemblies, in particular large ones,
more than strictly needed while building.
E.g. a build including a very large 1.3GB assembly, with several
native libraries embedded, save a lot of time avoiding the rewrites
mtouch (before)
Total time: 64202 ms
mtouch (after)
Total time: 34840 ms
* Add XM support for RemoveUserResourcesSubStep
* Tests supplied by @chamons
* [mtouch] Add missing HasParameters check inside linker and static registrar
Without the checks new, empty collections can be allocated and their
whole and only purpose will be to iterate up to 0 (nop).
The checks saves a small amount of memory (collections) and time.
* [registrar] Fix method comparison when they have no parameters
SDK assemblies might contain P/Invokes to libmono, but unless we link with
mono (which we don't do if we're not embedding mono), the native linker will
complain if we ask it to keep those symbols (using `-u symbol`).
So don't look for __Internal P/Invokes in SDK assemblies in that case.
https://bugzilla.xamarin.com/show_bug.cgi?id=45902
* [tests] Remove Classic SDK tests.
* Remove XI/Classic support.
This also means we can remove support for the legacy registrars.
* [monotouch-test] Remove legacy registrar tests.
* [tests/mtouch] Remove Classic tests (and legacy registrar logic).
* [tests/scripted] Fix tests to reference Xamarin.iOS.dll.
The MT2001 error is a general, something went bad, in the linker code
base. The stack trace is often enough to track down issues but in some
cases it would be easier to ask customers for a specific assembly
(rather than their complete project) to investigate an issue.
Example:
error MT2103: Binding Optimizer failed processing `System.Void GoogleConversionTracking.Unified.GoogleConversionPing::.ctor()`.
--- inner exception
System.NullReferenceException: Object reference not set to an instance of an object
at MonoTouch.Tuner.OptimizeGeneratedCodeSubStep.ProcessIsDirectBinding (Mono.Cecil.MethodDefinition caller, Mono.Cecil.Cil.Instruction ins) [0x00026] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/MonoTouch.Tuner/OptimizeGeneratedCodeSubStep.cs:264
at MonoTouch.Tuner.OptimizeGeneratedCodeSubStep.ProcessCalls (Mono.Cecil.MethodDefinition caller, Int32 i) [0x00337] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/MonoTouch.Tuner/OptimizeGeneratedCodeSubStep.cs:197
at MonoTouch.Tuner.OptimizeGeneratedCodeSubStep.Process (Mono.Cecil.MethodDefinition method) [0x0007b] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/MonoTouch.Tuner/OptimizeGeneratedCodeSubStep.cs:81
at Xamarin.Linker.StateSubStep.ProcessMethod (Mono.Cecil.MethodDefinition method) [0x00004] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/CoreOptimizeGeneratedCode.cs:48
---
at Xamarin.Linker.StateSubStep.ProcessMethod (Mono.Cecil.MethodDefinition method) [0x00014] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/CoreOptimizeGeneratedCode.cs:50
at Mono.Tuner.SubStepDispatcher.DispatchMethod (Mono.Cecil.MethodDefinition method) [0x0001d] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:215
at Mono.Tuner.SubStepDispatcher.BrowseMethods (ICollection methods) [0x0001c] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:167
at Mono.Tuner.SubStepDispatcher.BrowseTypes (ICollection types) [0x0006b] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:145
at Mono.Tuner.SubStepDispatcher.BrowseAssemblies (IEnumerable`1 assemblies) [0x00050] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:123
at Mono.Tuner.SubStepDispatcher.Process (Mono.Linker.LinkContext context) [0x0000f] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:104
at Mono.Linker.Pipeline.Process (Mono.Linker.LinkContext context) [0x00027] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/linker/Mono.Linker/Pipeline.cs:118
at MonoTouch.Tuner.Linker.Process (MonoTouch.Tuner.LinkerOptions options, MonoTouch.Tuner.MonoTouchLinkContext& context, System.Collections.Generic.List`1& assemblies) [0x000ac] in /Users/poupou/git/xamarin/xamarin-macios/tools/mtouch/Tuning.cs:79
Right now the MT2001 would only include the inner exception, which does
not include any clue to which assembly caused the exception.
Note: The same pattern to be applied to other BaseSubStep subclasses in
separate commits.
Related to (but not the fix for) https://bugzilla.xamarin.com/show_bug.cgi?id=44701
Some binding assemblies contains extra, unneeded code, generated by the C# compiler, e.g.
IL_002f: stloc.0
IL_0030: ldloc.0
which the binding optimizer did not expect.
https://bugzilla.xamarin.com/show_bug.cgi?id=44701
* Bump [watch-]mono to master to get fix for #43658.
https://bugzilla.xamarin.com/show_bug.cgi?id=43658
* [mtouch/mmp] Fix build after breaking cecil update in mono.
Also use mono's cecil instead of our own cecil submodule for mtouch.
* Bump [watch-]mono to get compilation fixes after cecil bump in mono.
* Remove cecil submodule, we only use the one in mono now.
mtouch only uses Xamarin.Mac to read plists, so change to use
our purely managed plist reader in Xamarin.MacDev instead.
That makes us able to change mtouch to be a normal command-line
executable (and project).
Which makes it logical to not mkbundle mtouch anymore,
it executes just fine with the system mono (and there's
no code to protect anymore either).
And since mmp and mtouch share some files, do the same
for mmp.