Auto-install locally after building in the IDE, so that running mtouch tests
after running the mtouch project doesn't require switching to the command
line.
The `generic_icollection_class` condition (in class.c) does not match the mscorlib.xml descriptor file.
+ IEnumerator`1
+ IReadOnlyList`1
+ IReadOnlyCollection`1
reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=50290
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).
Fixes this test failure:
Xamarin.Registrar.MT4161 : Unexpected error/warning with --registrar:static:
error MT0000: Unexpected error - Please file a bug report at http://bugzilla.xamarin.com
* [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.
* [mtouch] Always require a SDK version when building.
Technically it was required before too, but the error messages were non-optimal:
it could for instance complain that the user is using an iOS framework that
was introduced in iOS 2.0.
* [mtouch tests] Rewrite MT0060 and MT0061 tests to use MTouchTool.
This makes sure we pass --sdk to mtouch (which MTouchTool does by default), so
that we don't run into MT0025 before the errors we're testing for.
Add support for specifying the profile with the target framework,
and support using "Version=" before the version:
Xamarin.Mac,Version=v2.0,Profile=Mobile.
The BundleId property is used by the code that generates the mSYM directory,
but its value was always the default value 'com.yourcompany.sample' instead of
looked up in the app's Info.plist.
So fix the BundleId property to do the expected.
Also fix the mSYM test (SymbolicationData) to actually test mSYM stuff (it was
partially disabled when we disabled automatic mSYM generation for C8, and
never re-enabled), and port it to the new and better test syntax, and add a
few more asserts to check the manifest.xml generation.
-lsqlite3 is a linker flag, not a file to be linked with, so when
automatically determining that we need to pass -lsqlite3 we need to put it in
the right list of linker information.
Otherwise we may end up passing `-force_load -lsqlite3` to the linker (if the
assembly's ForceLoad flag is set), which won't compile.
https://bugzilla.xamarin.com/show_bug.cgi?id=49220
* [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
- `LoggingExtensions` has a new `MTError` extension method that helps generate
an msbuild error with the proper MTxxx format.
- Added error codes for 44 msbuild errors.
- Updated `docs/website/mtouch-errors.md` and `tools/mtouch/error.cs` accordingly.
- MT7001 contains some extra documentation (troubleshooting steps).
* [mtouch] Bring back PreBuildDirectory
Some mtouch unit tests failed because of timestamp checks. It's not clear
it's always a win (it's not in my original test case) not to copy (to
target) as it means we have to copy earlier (PreBuild + Build).
More investigation needed, there's probably a better way to achieve both.
In the mean time this should fix the failing tests cases.
* Fix up / simplify logic and avoid duplicate calls to IsUpdate
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.
Earlier versions of Xamarin Studio stored an invalid http message handler in
watchOS project files, which would cause a build error. In addition Xamarin
Studio removed the UI to set the http message handler (since only one value is
valid), which meant that the user had to edit the project file by hand to get
around this build error.
So make it a warning instead (and document what the user has to do to fix the
warning).
https://bugzilla.xamarin.com/show_bug.cgi?id=46552
Use metadata tokens instead of strings to find types and methods.
This makes the code to find methods more compact (a lot less strings in the
executable, and additionally in most cases a compact representation (32-bit
integer) of the corresponding metadata token and additional information can be
used, which results in less executable code (fewer parameters to methods,
etc)), resulting in smaller executables.
Size savings are around 200kb for dont link apps, and 20-60kb for linked apps
(this obviously varies a lot depending on how much has to registered by the
registrar).
| | Before | After | Diff |
|----------------|--------------:|--------------:|------------------:|
| dontlink/32bit | 102.810.144 | 102.609.456 | -200.688 = -0,20% |
| dontlink/64bit | 107.420.576 | 107.221.792 | -198.784 = -0,19% |
| linksdk/32bit | 40.957.296 | 40.936.864 | -20.432 = -0,05% |
| linksdk/64bit | 43.113.136 | 43.093.936 | -19.200 = -0,04% |
| linkall/32bit | 38.410.032 | 38.348.288 | -61.744 = -0,16% |
| linkall/64bit | 40.315.200 | 40.267.344 | -47.856 = -0,12% |
Additionally I've removed the `lazy_map` dictionary, which we populated at
startup and was used to map between Class instances and the corresponding
managed type's FullName, and instead iterate over a native array of Class ->
metadata token mappings whenever we need to look up the managed type for a
certain Class instance.
This is slightly slower for each type we need to look up (for a non-linked app
there might be a 2000-3000 entries in the native array, which would be
iterated instead of using a hashtable lookup), but it's only done once per
type and there's a significant startup memory improvement.
For a non-linked test app I get the following using the Xamarin profiler:
| | Before | After | Diff |
|-------------------|--------:|--------:|----------------:|
| Memory allocated | 2,8 MB | 2,4 MB | -0,4 MB = -14 % |
| Objects allocated | 43678 | 38463 | -5215 = -12 % |
| Private bytes | 26,6 MB | 24,4 MB | -2,2 MB = -8,3% |
| Working set | 26,6 MB | 24,4 MB | -2,2 MB = -8,3% |
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
Run the partial static registrar separately for 32-bit and 64-bit, since this
is required with the upcoming changes to embed metadata tokens inside the
generated output, because the metadata tokens are different between the 32-bit
and 64-bit versions of Xamarin.iOS.dll.
Also make sure to properly resolve the 32-bit and 64-bit assemblies correctly
(by setting the ArchDirectory on the assembly resolver), so that we don't pick
up the reference assembly (which does not have the right metadata tokens).
Additionally stop running the partial static registrar for MonoTouch.Dialog-1,
since with the upcoming changes to use metadata tokens in the generated
output, we won't support registering anything more than once. This shouldn't
make much of an impact, because MonoTouch.Dialog-1 is fairly small, and
doesn't take long to register in the dynamic registrar. For device builds (or
when the static registrar is selected) this has no effect, since in that case
we're registering everythinga anyway.
Link the executable with LinkWith attributes' libraries in the simulator when
doing incremental builds, since we don't create dylibs there.
Fixes several mtouch test failures:
1) Test Failure : Xamarin.MTouch.FastDev_NoFastSim_LinkAll(Unified)
2) Test Failure : Xamarin.MTouch.FastDev_NoFastSim_LinkAll(TVOS)
3) Test Failure : Xamarin.MTouch.FastDev_NoFastSim_LinkSDK(Unified)
4) Test Failure : Xamarin.MTouch.FastDev_NoFastSim_LinkSDK(TVOS)
5) Test Failure : Xamarin.MTouch.FastDev_NoFastSim_NoLink(Unified)
6) Test Failure : Xamarin.MTouch.FastDev_NoFastSim_NoLink(TVOS)
7) Test Failure : Xamarin.MTouch.FastDev_Sim(Unified)
8) Test Failure : Xamarin.MTouch.FastDev_Sim(TVOS)
Update mdb files even if the corresponding assembly didn't change, because the
mdb can change even if the assembly didn't (if whitespace was modified in the
source code, causing code lines to move).
https://bugzilla.xamarin.com/show_bug.cgi?id=39535
If the cache is invalid we print a warning:
> A full rebuild will be performed because the cache is either incomplete or entirely missing.
and set `Driver.Force = true;` (in Application.cs).
This later means that extracting the native code is done on each target:
```
public static bool IsUptodate (string source, string target)
{
if (Driver.Force)
return false;
```
even if this is identical between 32 and 64 bits (targets). That's
inefficient and, for large binding libraries (e.g. > 1GB), has a
noticable impact on build time (see timestamps).
Considering that the cache is cleaned (when detected as invalid) then
this Force condition is not really needed.
E.g. in `IsUptodate`
* the first time (arch) it's called will have to extract the native library;
* if a 2nd arch is built (fat) then it will be found as present and will
not be extracted again
Removing the `Driver.Force = true;` in this condition let the `-f` option
continue to extract it twice, which can be useful in debugging and testing.
As such the check is not removed from `IsUptodate`
Timestamps (before)
Setup: 25 ms
Resolve References: 1605 ms
Extracted native link info: 10465 ms
...
Timestamps (after)
Setup: 24 ms
Resolve References: 1560 ms
Extracted native link info: 5473 ms
...
Total build times (from XS) was around 90-100 seconds so 5 seconds is
about 10%. The actual savings will depend on how much native code needs
to be extracted, but it should help most release builds (almost always
fat builds).
* Comment is wrong: the code is never executed in parallel
* If reached then RemoveResources will be called and already check for
symbols (and load them when needed). Just a simplification (it won't
really save time as it's not loaded twice)
IIRC this used to be needed with a (rather old) version of Cecil.
The current code does nothing as the Load will only hit the cache
and not other properties are changed (compared to the old commented
code)
* [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
The SDK does not ship any, non-tool, .exe files. In fact .exe _should_
never need to be resolved since the main .exe is always given as an input
to mtouch.
Still it's possible (if quite uncommon) to refer to other .exe assemblies
just like if they were .dll. However those can only come from the
RootDirectory (and not the other places that ship with the SDK).
This "fix" ensure lookups for *.exe is done only inside the RootDirectory
location, speeding up (a bit) resolving assemblies.
Native libraries are already linked into the dylib for the binding assembly,
which means that if we also link it into the main executable, the native code
ends up twice in the app (which is bad for many reasons).
https://bugzilla.xamarin.com/show_bug.cgi?id=42473
The container app may not reference the same third-party frameworks as
extensions, which means that we must make sure the extension's frameworks are
also included in the app bundle.
So when building extensions save a list of all third-party frameworks, and
then read that list and include those frameworks when building the main app.
https://bugzilla.xamarin.com/show_bug.cgi?id=45800
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
This makes it possible to set linker flags per assembly:
[assembly: LinkWith (LinkerFlags = "-lsqlite3")]
Which is required when incremental builds is enabled and a particular assembly
needs special linker flags (because we don't propagate the global -gcc_flags
to each dylib we build when doing incremental builds).
Also add an option to set the dlsym mode for an assembly (using the LinkWith
attribute).
Duration before: 1,60s
Duration after: 1,54s
Difference: -0,06s = -3,8%
Memory usage hardly changed (-21 kb of 540 MB), but the number of method calls
shrunk significantly.
Method calls before: 86.720.379
Method calls after: 74.390.061
Difference: -12.330.318 = -14,2%
The call to `GetSystemVoidType` was #2 on the list of method calls (whens
sorted by 'self'), called 1072 times taking 1429 ms each time. After this
change it's only called once (and obviously pushed way down the list).
Setting this option prints this to stdout:
> Mono Warning: option gen-compact-seq-points is deprecated.
and it's ignored, so just don't set this option.
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
Unify the code to determine whether a particular return type requires a stret
signature or not between the generator and platform assemblies.
Also fix the stret detection for armv7k, whose calling convention is not
identical to armv7(s): there's the concept of homogeneous structures, which
contains multiple elements of only one type, and which is sometimes passed in
registers on armv7k.
https://bugzilla.xamarin.com/show_bug.cgi?id=44709
For Unified, set XAMCORE_2_0, UNIFIED and __UNIFIED__.
For Xamarin.iOS/tvOS/watchOS set both the normal and underscored versions
(IOS and __IOS__, TVOS and __TVOS__, and WATCHOS and __WATCHOS__).
The underscored versions are the public symbols we're setting in the
corresponding projects, so we should use those everywhere to simplify our
code, but due to historical reasons we're still using the other variants in
existing code.
Making sure all the possible variants are set for all projects, makes it
possible to only use the underscored versions in new code.
Also define `GENERATOR` for the generator, so that we can easily share
files between the generator and platform assemblies.
Fix NullReferenceException in PInvoke wrapper generation when incremental
builds are enabled and the linker didn't run because cached results were
found.
https://bugzilla.xamarin.com/show_bug.cgi?id=44763
In the recent Cecil update Cecil changed from loading assemblies in memory to
keep a FileStream around and read whenever necessary [1].
This is problematic for us, because we need all the AssemblyDefinitions in
memory at once, and if there are many assemblies, then we'll run into problems
due to the number of file descriptors in use.
So revert to the behavior for the old Cecil: loading assemblies in memory,
unless the assemblies are big, since in that case we might run out of memory
otherwise.
http://cecil.pe/post/149243207656/mono-cecil-010-beta-1
* [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
The nested Parallel.ForEach loops don't take into account the outer
MaxDegreeOfParallelism value, causing us to spawn more concurrent tasks than
we want to.
So refactor the code to have one static list of tasks, which each subtask adds
to.
The nested Parallel.ForEach loops don't take into account the outer
MaxDegreeOfParallelism value, causing us to spawn more concurrent tasks than
we want to.
So refactor the code to have one static list of tasks, which each subtask adds
to.
* Fix default http message handler for watchOS.
Fix default http message handler for watchOS to be NSUrlSessionHandler (the
previous attempt at eb7c2fd was quite incomplete), and make sure
HttpClientHandler is never used (show errors if someone tries).
* [tests] Remove explicit http client handler from project files.
Just use the default instead, since the set of valid http client handlers varies between platforms.
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.
This is something that changed with 70f1346b: our libxamarin.dylib now
requires iOS 8+, which means the app itself must require iOS 8+ when using
libxamarin.dylib.
This fixes an msbuild failure (Xamarin.iOS.Tasks.IBToolLinking("iPhone").BuildTest):
Process exited with code 1, command:
/Applications/Xcode73.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -framework Foundation -framework UIKit /Users/builder/data/lanes/1381/5f73edaa/source/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphoneos.sdk/usr/lib/libmonosgen-2.0.dylib /Users/builder/data/lanes/1381/5f73edaa/source/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphoneos.sdk/usr/lib/libxamarin-debug.dylib -lz -isysroot /Applications/Xcode73.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.3.sdk -Qunused-arguments -miphoneos-version-min=7.0 -arch armv7 -shared -read_only_relocs suppress -install_name @executable_path/libXamarin.iOS.dll.dylib -fapplication-extension -o /Users/builder/data/lanes/1381/5f73edaa/source/xamarin-macios/msbuild/tests/MyIBToolLinkTest/obj/iPhone/Debug/mtouch-cache/Xamarin.iOS.dll.armv7.dylib -x assembler /Users/builder/data/lanes/1381/5f73edaa/source/xamarin-macios/msbuild/tests/MyIBToolLinkTest/obj/iPhone/Debug/mtouch-cache/Xamarin.iOS.dll.armv7.s -DDEBUG
ld: warning: embedded dylibs/frameworks only run on iOS 8 or later
ld: embedded dylibs/frameworks are only supported on iOS 8.0 and later (@executable_path/libxamarin-debug.dylib) for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)
We need to compile the generated P/Invoke wrappers to a dylib, and link the
dylib for the product assembly (Xamarin.WatchOS.dll) with the generated
P/Invoke wrappers.
Since there might be P/Invokes in any assembly, just link in the P/Invoke
wrapper dylib for every assembly.
https://bugzilla.xamarin.com/show_bug.cgi?id=44048
note: AVFoundation is commented on watchOS 3 as this breaks the static
registrar .a helper built for watchOS.
AVFoundation does a file check to enable some types - but the watchSimulator
include that file, leading to compilation errors later (missing CMTime.h)
#if TARGET_OS_WATCH
#if ! __has_include(<AVFoundation/AVAnimation.h>)
#define AVF_IS_WATCHOS_SDK 1
#endif
#endif
The real fix for bug #43658 is in mono master, but the current
version of mono master doesn't build for us, so implement this
workaround instead.
The problem is that the linker doesn't preserve fields of nested types marked
in xml descriptions unless the declaring type is marked. So the workaround
(until we can bump mono) is to mark the declaring type.
https://bugzilla.xamarin.com/show_bug.cgi?id=43658
* 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.
This way we use the right version of any dependent dlls.
Otherwise we'd build with the cecil version from the mono repository,
and run with the system's cecil.
* [Mtouch] Use the mono tools to copy over the msym files.
* As per review:
* Do not create a DirectoryInfo when it is not needed.
* Do not throw exceptions for values that can be null, should never
happen.
* Remove unused import.
* Undo a wrong using removal and do the right thing.
* Fix build issues.
* [C8] Bump to latest Mono 4.6.0 commit
Brings in the netstandard updates from https://github.com/mono/mono/pull/3394
We also had to add a new assembly System.IdentityModel.dll to the mobile profiles while doing that work.
* Add System.IdentityModel to Sdk assemblies
Fixes the following mtouch test failure:
```
Xamarin.Linker.SdkTest.iOS_Classic : BCL
Expected:
But was: < "System.IdentityModel" >
at NUnit.Framework.CollectionAssert.IsEmpty (IEnumerable collection, System.String message, System.Object[] args) <0x47bec88 + 0x00047> in :0
at NUnit.Framework.CollectionAssert.IsEmpty (IEnumerable collection, System.String message) <0x47bec58 + 0x0001f> in :0
at Xamarin.Linker.SdkTest.BCL (System.String path) <0x47bccf0 + 0x003f3> in :0
at Xamarin.Linker.SdkTest.iOS_Classic () <0x47bcc50 + 0x0001b> in :0
```
Fixes the following mtouch test failure:
```
Xamarin.Linker.SdkTest.iOS_Classic : BCL
Expected:
But was: < "System.IdentityModel" >
at NUnit.Framework.CollectionAssert.IsEmpty (IEnumerable collection, System.String message, System.Object[] args) <0x47bec88 + 0x00047> in :0
at NUnit.Framework.CollectionAssert.IsEmpty (IEnumerable collection, System.String message) <0x47bec58 + 0x0001f> in :0
at Xamarin.Linker.SdkTest.BCL (System.String path) <0x47bccf0 + 0x003f3> in :0
at Xamarin.Linker.SdkTest.iOS_Classic () <0x47bcc50 + 0x0001b> in :0
```
- 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
- 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
* Enable some SceneKit-related WatchKit API
* Enable some SceneKit-related SpriteKit API
* Enable some SceneKit-related Foundation API
* Fix generator to include `using SceneKit;` on watchOS
* Adjust xtro tests since watchOS headers include some stuff that's not available in reality
* Lots of [Watch (3,0)] attributes
This is only applicable to tvOS 10 (i.e. the xcode8 branch),
but applying the patch already helps avoiding merge failures
for other fixes in the same area.
* 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
We tried disabling dlsym for all assemblies on iOS, but it turned
out to break a significant amount of customer code [1].
So re-enable it, but only for user assemblies (since we control
all assemblies we ship and can thus make sure those work with
dlsym disabled).
https://trello.com/c/guig1MF2/623-re-enable-dlsym-for-ios
We tried disabling dlsym for all assemblies on iOS, but it turned
out to break a significant amount of customer code [1].
So re-enable it, but only for user assemblies (since we control
all assemblies we ship and can thus make sure those work with
dlsym disabled).
https://trello.com/c/guig1MF2/623-re-enable-dlsym-for-ios
Fixes the Sdk test:
Errors and Failures:
1) Test Failure : Xamarin.Linker.SdkTest.iOS_Classic
System.Security.Cryptography.Algorithms
Expected: True
But was: False
at Xamarin.Linker.SdkTest.Facades (System.String path) <0x30d4640 + 0x0006f> in <filename unknown>:0
at Xamarin.Linker.SdkTest.iOS_Classic () <0x30d2808 + 0x0004b> in <filename unknown>:0
2) Test Failure : Xamarin.Linker.SdkTest.iOS_Unified
System.Security.Cryptography.Algorithms
Expected: True
But was: False
at Xamarin.Linker.SdkTest.Facades (System.String path) <0x30d4640 + 0x0006f> in <filename unknown>:0
at Xamarin.Linker.SdkTest.iOS_Unified () <0x30d5558 + 0x0004b> in <filename unknown>:0
3) Test Failure : Xamarin.Linker.SdkTest.tvOS
System.Security.Cryptography.Algorithms
Expected: True
But was: False
at Xamarin.Linker.SdkTest.Facades (System.String path) <0x30d4640 + 0x0006f> in <filename unknown>:0
at Xamarin.Linker.SdkTest.tvOS () <0x30d55d8 + 0x0004b> in <filename unknown>:0
4) Test Failure : Xamarin.Linker.SdkTest.watchOS
System.Security.Cryptography.Algorithms
Expected: True
But was: False
at Xamarin.Linker.SdkTest.Facades (System.String path) <0x30d4640 + 0x0006f> in <filename unknown>:0
at Xamarin.Linker.SdkTest.watchOS () <0x30d5658 + 0x0004b> in <filename unknown>:0
* [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
Fixes the Sdk test:
Errors and Failures:
1) Test Failure : Xamarin.Linker.SdkTest.iOS_Classic
System.Security.Cryptography.Algorithms
Expected: True
But was: False
at Xamarin.Linker.SdkTest.Facades (System.String path) <0x30d4640 + 0x0006f> in <filename unknown>:0
at Xamarin.Linker.SdkTest.iOS_Classic () <0x30d2808 + 0x0004b> in <filename unknown>:0
2) Test Failure : Xamarin.Linker.SdkTest.iOS_Unified
System.Security.Cryptography.Algorithms
Expected: True
But was: False
at Xamarin.Linker.SdkTest.Facades (System.String path) <0x30d4640 + 0x0006f> in <filename unknown>:0
at Xamarin.Linker.SdkTest.iOS_Unified () <0x30d5558 + 0x0004b> in <filename unknown>:0
3) Test Failure : Xamarin.Linker.SdkTest.tvOS
System.Security.Cryptography.Algorithms
Expected: True
But was: False
at Xamarin.Linker.SdkTest.Facades (System.String path) <0x30d4640 + 0x0006f> in <filename unknown>:0
at Xamarin.Linker.SdkTest.tvOS () <0x30d55d8 + 0x0004b> in <filename unknown>:0
4) Test Failure : Xamarin.Linker.SdkTest.watchOS
System.Security.Cryptography.Algorithms
Expected: True
But was: False
at Xamarin.Linker.SdkTest.Facades (System.String path) <0x30d4640 + 0x0006f> in <filename unknown>:0
at Xamarin.Linker.SdkTest.watchOS () <0x30d5658 + 0x0004b> in <filename unknown>:0
Category methods are exposed like extension methods, and the first parameter
specifies the class, which means we need to skip the first type when generating
the ObjC signature.
https://bugzilla.xamarin.com/show_bug.cgi?id=42489
There can be circular dependencies between Objective-C classes,
so make sure we don't fail compilation when that occurs by
forward declaring any Objective-C classes/protocols.
The test case in question does not contain a circular dependency,
but the same issue occurs due to types not being generated in the
correct order (a correct order could be constructed for the test
case, but there's no general solution since circular dependencies
can exist).
https://bugzilla.xamarin.com/show_bug.cgi?id=42454
Category methods are exposed like extension methods, and the first parameter
specifies the class, which means we need to skip the first type when generating
the ObjC signature.
https://bugzilla.xamarin.com/show_bug.cgi?id=42489
There can be circular dependencies between Objective-C classes,
so make sure we don't fail compilation when that occurs by
forward declaring any Objective-C classes/protocols.
The test case in question does not contain a circular dependency,
but the same issue occurs due to types not being generated in the
correct order (a correct order could be constructed for the test
case, but there's no general solution since circular dependencies
can exist).
https://bugzilla.xamarin.com/show_bug.cgi?id=42454
Fixes NSCharacterSetTest.NSMutableCharacterSet_TestStaticSets when
running with the P/Invoke wrapper (for exceptions) enabled (i.e.
watchOS), since otherwise the wrapper would truncate char parameters
to byte.
* Added Speech Framework bindings
* Ensured introspection test pass
* Ensured we link against Speech framework
* FIXME: SFSpeechRecordingRecognitionRequest is not in the public api
filled radar://26799291 https://trello.com/c/s6s6YKua
* Added CallKit Bindings
* Ensure CallKit.framework is linked
* Ensure CallKit passes introspection tests
* FIXME: https://trello.com/c/afWXDZ3A
Headers says CallKit is available on macOS 10.12
but uses AVAudioSession and it is iOS only
Opened Radar awaiting response.
There's a clang bug [2] where if a selector is marked as unavailable,
it's marked as unavailable for every class, not just the class where
the unavailable selector is.
This means that we can't do `[super initWithCoder:x]` anywhere,
because `initWithCoder:` is marked as unavailable for UIActivityViewController.
So instead rewrite the call to super to call objc_msgSendSuper
directly, circumventing clang's broken availability checks.
[1] https://bugzilla.xamarin.com/show_bug.cgi?id=41319
[2] https://llvm.org/bugs/show_bug.cgi?id=28058
[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.
This is because Mono doesn't build a libmono-profiler-log.dylib when
bitcode is enabled, so we can't support profiling + fastdev at the same
time.
Hopefully mono will fix this (see bug#41428) soon, in which case
this code can be removed.
https://bugzilla.xamarin.com/show_bug.cgi?id=41428
* [XM] Teach XM's mmp tool to handle read only assemblies/native libs
- https://bugzilla.xamarin.com/show_bug.cgi?id=41037
- mmp should also promote any install_name_tool errors to "real" errors
* Bump maccore
In cycle 7 we turned off, by default, the `dlsym` option (i.e. looking
up symbols for p/invoke) for tvOS and watchOS.
However we decided to wait for iOS to see if this caused issues for
existing code base. There has not been such reports (for tvOS) so,
for cycle 8, we'll turn it off (and use direct calls) for iOS.
If problems arise during the alpha/beta of C8 then we still can
revert this change easily.
Chris Hamons
Rolf Bjarne Kvinge
Vincent Dondain
Sebastien Pouliot
Vincent Dondain
Zoltan Varga
Sebastien Pouliot
Martin Baulig
Manuel de la Pena
Manuel de la Pena
Alexander Köplinger
Aleksey Kliger (λgeek)
Alex Soto
Alex Soto
Timothy Risi