- Update comments on XM45.targets file
- Remove unnecessary AssemblySearchPaths hack causing issues using nugets with same name as Facades
- Note: MSBuild with XM 4.5 is still broken for now
* [XM] Seperate parsing from compilation in AOT code
- Parsing command line options was too entangled with actually compiling
- Refactor test code to centralize Compile, reducing some complexity of tests
- Groundwork for hybrid vs non-hybrid AOT work
* Add hybrid/standard AOT support
* Add xammac_tests to makefile/jenkins
* Add flag to force AOT
* Disable MonoTouchFixtures.Contacts.ContactStoreTest.GetUnifiedContacts on XM due to prompts on Jenkins
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=52238
If you give mtouch/mmp a linker xml file with bad input for
example a Xamarin.iOS app and the linker.xml has a reference
to Xamarin.Mac instead of X.I.dll i.e.
<?xml version="1.0" encoding="UTF-8" ?>
<linker>
<assembly fullname="Xamarin.Mac">
<type fullname="ObjCRuntime.Constants"/>
</assembly>
</linker>
You will get a not so helpful generic error
MT2001 Could not link assemblies. Reason: Failed to process XML description: <unspecified>
It seems that when you use a xml file for linker you get a
`XmlResolutionException` from cecil when it fails to resolve
and the better error comes from the inner exception so we use
that instead.
New error output for XmlResolutionException:
MT2017: Could not process XML description: Failed to resolve assembly: 'Xamarin.Mac, Culture=neutral, PublicKeyToken=null'
Resource files for mac should be copied to the app bundle
* Move the Satellite code used by mac to tools/common/Assembly.cs
* Add EmbeddedResources test to xammac_tests
So that there can be multiple caches in the same process (which we'll have
once mtouch can compile extensions and the container app in the same process).
* [mtouch] Remove most static state and put it on an instance.
Remove most static state, and put it on an instance (of Application) instead.
Soon we'll build multiple apps (app extensions) in the same process, and we
need to make sure we're not inadvertedly (and incorrectly) sharing state
between apps, so remove as much static state as possible to avoid any
problems.
* [mtouch] Rename GetIsUsingClang -> IsUsingClang.
* [XM] Change mmp defaults to static registrar and disable lldb attach in release mode
- Static registrar is now proven and can be flipped on for default on release
- LLDB attach isn't very helpful in release mode and pops up the install xcode dialog
- Relax Unified_HelloWorld_ShouldHaveNoWarnings to exclude static registrar warnings due to https://bugzilla.xamarin.com/show_bug.cgi?id=48311
The old `legacy` option will now be reported as a warning.
That's by design an warning would require manually editing the .csproj
file (when the UI gets removed, as planned, from the IDE).
This is part of
https://trello.com/c/SrgU38DN/647-only-ship-support-appletls
Note: The BCL changes will happen in later stages.
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
Managed exception marshaling interferes with the debugger, because it adds
exception handlers to executing code, which makes the Mono runtime think an
exception is handled when logically it's not (although technically it is).
The consequence is that the IDEs will only be notified when we re-throw the
exception after catching it, making it impossible for the IDEs to stop when
the exception is thrown (they will instead stop when we re-throw the
exception).
So disable managed exception marshaling (unless the user changed the default
behavior) when a debugger is attached.
This is the same behavior as Xamarin.Android.
https://bugzilla.xamarin.com/show_bug.cgi?id=45116
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
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
We've used the dynamic registrar for years now when selecting the IL registrar
(and I've never heard about anybody doing it), so just remove all the related
(and in fact dead) code.
* 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.
- Linking breaks extensions for as long as we have the "extensions must be use static registrar" hack.
- So let's ignore it with a warning. Better that random brokeness.
- https://bugzilla.xamarin.com/show_bug.cgi?id=43197
* Bump mono and watch-mono
* [mmp] Preserve TransparentProxy::StoreRemoteField
This is needed to prevent a mono assert when xamarin-macios is built
with mono master after mono/mono@6b8e96c
* [XM] Fix linker ability to deadstrip library loads from NSObject.mac.cd for new libraries
- Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=42177 in Release / Mobile since we can rip out GameController if not used
[XM] Add release value option to msbuild/mmp to resolve XM 4.5 assemblies from system GAC
- This option "reverts" a C7 fix that prevented resovling assemblies from the GAC, which is unsafe
- If you use this option, you need to know what you are doing. The mono BCL and the XM BCL need to be compatible
- Use strictly puts you in the no support "you get to keep the pieces if it breaks" category.