Several functions were 100% identical except for their signature. However
the signature were over-specialized and simplifying them allows the
(already) present code merge feature to achieve much better results.
Final size impact will vary based on the API used (both the managed and
native linker can remove some) but the more API you use the more likely
the application included duplicate code.
**Before**
`tools/mtouch/Xamarin.iOS.registrar.ios.x86_64.m` has `native_to_managed_trampoline_[1..379]`
```
find tools/ -name Xamarin.*.a | xargs ls -l
-rw-r--r-- 1 poupou staff 4143148 11 Oct 15:09 tools//mmp/Xamarin.Mac.registrar.full.a
-rw-r--r-- 1 poupou staff 4139052 11 Oct 15:09 tools//mmp/Xamarin.Mac.registrar.full.x86_64.a
-rw-r--r-- 1 poupou staff 4143160 11 Oct 15:09 tools//mmp/Xamarin.Mac.registrar.mobile.a
-rw-r--r-- 1 poupou staff 4139064 11 Oct 15:09 tools//mmp/Xamarin.Mac.registrar.mobile.x86_64.a
-rw-r--r-- 1 poupou staff 4521752 11 Oct 15:09 tools//mtouch/Xamarin.iOS.registrar.ios.i386.a
-rw-r--r-- 1 poupou staff 9240416 11 Oct 15:09 tools//mtouch/Xamarin.iOS.registrar.ios.simulator.a
-rw-r--r-- 1 poupou staff 4714336 11 Oct 15:09 tools//mtouch/Xamarin.iOS.registrar.ios.x86_64.a
```
**After**
`tools/mtouch/Xamarin.iOS.registrar.ios.x86_64.m` has `native_to_managed_trampoline_[1..132]`
```
find tools/ -name Xamarin.*.a | xargs ls -l
-rw-r--r-- 1 poupou staff 3723012 11 Oct 14:57 tools//mmp/Xamarin.Mac.registrar.full.a
-rw-r--r-- 1 poupou staff 3718916 11 Oct 14:57 tools//mmp/Xamarin.Mac.registrar.full.x86_64.a
-rw-r--r-- 1 poupou staff 3723016 11 Oct 14:57 tools//mmp/Xamarin.Mac.registrar.mobile.a
-rw-r--r-- 1 poupou staff 3718920 11 Oct 14:57 tools//mmp/Xamarin.Mac.registrar.mobile.x86_64.a
-rw-r--r-- 1 poupou staff 3995520 11 Oct 14:57 tools//mtouch/Xamarin.iOS.registrar.ios.i386.a
-rw-r--r-- 1 poupou staff 8195748 11 Oct 14:57 tools//mtouch/Xamarin.iOS.registrar.ios.simulator.a
-rw-r--r-- 1 poupou staff 4193956 11 Oct 14:57 tools//mtouch/Xamarin.iOS.registrar.ios.x86_64.a
```
The result of `lipo`ing `.a`s and `.dylib`s together is not well defined.
In this specific case, using `lipo` on `libmonosgen-2.0.a` to inject `x86-64-slice.dylib` resulted into `dsymutil` (run by `mtouch` when building the app) not finding the proper debug information anymore.
Also putting the dummy slice into a file and adding `-ggdb3` to avoid those warnings:
```console
$ dsymutil ./_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphoneos.sdk/usr/lib/libmonosgen-2.0.dylib
warning: (x86_64) /var/folders/p3/5279mmgn1p575bz28j0ngfqw0000gn/T/--19c1b5.o unable to open object file: No such file or directory
warning: no debug symbols in executable (-arch x86_64)
```
The existing test only checked that an assembly was mentioned in the file, but not that its version etc matches.
Updated the test and fixed the differences.
Fix building the test libraries so that the native compiler gets passed the
right arguments (which makes us build the tvOS and watchOS versions of these
libraries with bitcode).
This fixes a build problem with the framework-test test for tvOS and watchOS.
Also remove an outdated comment.
It does not look like an issue, at least today, since it's always set to
`false` but better fix it before it becomes an hard to debug issue
```
$ git grep "IsConstructor = "
src/ObjCRuntime/Registrar.cs: IsConstructor = false,
src/ObjCRuntime/Registrar.cs: IsConstructor = false,
src/ObjCRuntime/Registrar.cs: IsConstructor = false,
```
* Automatically build mono from source if any of the archives aren't available.
* [jenkins] Show in the PR report if mono was built from source.
* [jenkins] Make sure we got everything after running configure.
This has a couple of advantages:
* It makes it easier to add a catalyst version of these libraries (because it
becomes cumbersome to build for catalyst when the build rules assumes we're
building for both simulator and device).
* It makes it easier to create an xcframework of our libraries, because the
contents in an xcframework is split like this.
microsoft.com is doing user agent sniffing, and broke our our test since their
output is now different. Switch to example.com instead.
Fixes https://github.com/xamarin/maccore/issues/2006.
See https://github.com/mono/mono/issues/17064.
The 2019-08 version of the fix adds a new assembly with NS2.1 APIs that we stubbed out in 2019-06: System.Data.DataSetExtensions.dll
Fixes these warnings:
shared.m:252:6: warning: 'OSAtomicDecrement32Barrier' is deprecated: first deprecated in watchOS 3.0 - Use std::atomic_fetch_sub() from <atomic> instead [-Wdeprecated-declarations]
if (OSAtomicDecrement32Barrier (&bl->descriptor->ref_count) == 0) {
^
/Applications/Xcode11.app/Contents/Developer/Platforms/WatchOS.platform/Developer/SDKs/WatchOS6.0.sdk/usr/include/libkern/OSAtomicDeprecated.h:201:9: note: 'OSAtomicDecrement32Barrier' has been explicitly marked deprecated here
int32_t OSAtomicDecrement32Barrier( volatile int32_t *__theValue );
^
shared.m:270:2: warning: 'OSAtomicIncrement32' is deprecated: first deprecated in watchOS 3.0 - Use std::atomic_fetch_add_explicit(std::memory_order_relaxed) from <atomic> instead [-Wdeprecated-declarations]
OSAtomicIncrement32 (&source->descriptor->ref_count);
^
/Applications/Xcode11.app/Contents/Developer/Platforms/WatchOS.platform/Developer/SDKs/WatchOS6.0.sdk/usr/include/libkern/OSAtomicDeprecated.h:171:9: note: 'OSAtomicIncrement32' has been explicitly marked deprecated here
int32_t OSAtomicIncrement32( volatile int32_t *__theValue );
^
monotouch-debug.m:309:10: warning: 'OSAtomicIncrement32Barrier' is deprecated: first deprecated in watchOS 3.0 - Use std::atomic_fetch_add() from <atomic> instead [-Wdeprecated-declarations]
int c = OSAtomicIncrement32Barrier (&http_send_counter);
^
/Applications/Xcode11.app/Contents/Developer/Platforms/WatchOS.platform/Developer/SDKs/WatchOS6.0.sdk/usr/include/libkern/OSAtomicDeprecated.h:182:9: note: 'OSAtomicIncrement32Barrier' has been explicitly marked deprecated here
int32_t OSAtomicIncrement32Barrier( volatile int32_t *__theValue );
^
Tweak the watchOS architecture test to build for bitcode when building with
llvm, since that's what's usually done.
Also tweak the MT0145 error message a bit.
Fixes https://github.com/xamarin/maccore/issues/1994.
Types that are new in 64bits only OS are generated differently on 32bits
bindings. They mainly throw a `PlatformNotSupportedException` so it's
easier to diagnose (than a crash) what's happening at runtime.
This works well in all cases except one. When a new type, let's say
`UIMenuElement` is added **and** serves as a new base type for existing
types.
`UIKeyCommand` (iOS 7) -> `UICommand` (iOS 13)-> `UIMenuElement` (iOS 13)
This is _correct_ as new base types can be added (in ObjC and C#).
However the generated code for the constructors of `UICommand` and
`UIMenuElement` would be throwing a `PlatformNotSupportedException`
which breaks the `UIKeyCommand` on 32 bits devices.
We fixed this in a few places by tweaking the availability attribute
but that requires spotting the new base type while doing bindings and
that is error prone [1][2].
This PR simply does let the `protected` constructor, using when chaining,
be generated normally. It's simpler and will cover all the cases (without
requiring hacks in the availability of those types)
[1] https://github.com/xamarin/xamarin-macios/issues/7083
[2] https://github.com/xamarin/xamarin-macios/issues/7084
* [builds] add arm64_32 cross compiler
* [mtouch] force --interpreter on arm64_32 debug mode build
* [mtouch] include debug check for arm64_32 and reflect error codes in documentation
Add new overloads so we can skip `String.Format` calls when relaying
messages without any arguments. Solve cases like
```
error BI0000: Unexpected error - Please file a bug report at https://github.com/xamarin/xamarin-macios/issues/new
System.FormatException: Input string was not in a correct format.
at System.Text.StringBuilder.AppendFormatHelper (System.IFormatProvider provider, System.String format, System.ParamsArray args) [0x000b2] in /Users/builder/jenkins/workspace/build-package-osx-mono/2019-06/external/bockbuild/builds/mono-x64/external/corefx/src/Common/src/CoreLib/System/Text/StringBuilder.cs:1445
...
```
because we failed compilation due to an (hidden) syntax error like:
```
foundation.cs(3627,3): error CS1519: Invalid token '{' in class, struct, or interface member declaration
```
where the `{` character is causing the `FormatException` inside the
generator sources.
This is now more properly reported as
```
error BI0002: bgen: Could not compile the API bindings.
foundation.cs(3627,3): error CS1519: Invalid token '{' in class, struct, or interface member declaration
```
* Drop the Xcode 9.4 dependency.
Also bump mono to get the removal of the mac32 binaries.
New commits in mono/mono:
* mono/mono@70d6903053 [2019-08] [merp] Use a separate program as the hang supervisor. (#16900)
* mono/mono@4bff2b6370 [offsets-tool] Install clang into the user-specific python directory.
* mono/mono@81894ec8ca Implement WriteCore and ReadCore in DeflateStream
* mono/mono@bfbf823ca1 [ci] Remove more XCODE32_DIR usages (#16964)
* mono/mono@ce01b20a4d Add net_4.8.xml to EXTRA_DIST and bump binary-reference-assemblies again
* mono/mono@7a587d7fa6 Add .NET 4.8 reference assemblies (#16912)
* mono/mono@35e454a8f6 [sdks] Remove the mac32 build. (#16936)
* mono/mono@75eb342f53 [2019-08] [System] Make FileSystemWatcher backend non-static (#16926)
* mono/mono@5881981f79 [2019-08] [mini] Add missing membars when initializing rgctx entries (#16909)
* mono/mono@6290b6cd6e Temporarily disable embedded ppdb data decompression (#16911)
* mono/mono@a0e7f9eaf2 [2019-08] [arm64_32] make "Debug Mode" work on Watch series 4 with --interpreter (#16886)
* mono/mono@6275840a7f Rename bundle identifier for the various Mono.frameworks we create for Xamarin.iOS. Fixesxamarin/xamarin-macios#7005. (#16901)
* mono/mono@25f6093283 [corlib] Fix building nunit-lite twice (#16895)
* mono/mono@7ec17ba1be [2019-08] [android sdk] Add aprofutil tool (#16884)
* mono/mono@f755f3b539 [metadata] Fix leaks when handling a few attributes (#16850)
* mono/mono@5f9a2db39b [2019-08] Fix infrequent hangs in test-runner. (#16854)
* mono/mono@f31f5ea1f1 [2019-08] [threads] do not convert NULL thread name (#16828)
* mono/mono@20308e6f87 [aot] Do not wrap tool_prefix path when calling strip (#16820)
* mono/mono@cecda47c48 [aprofutil] Add -p and -f options
* mono/mono@824cc12ac3 Bump to mono/corefx@e79cf5b
* mono/mono@b77dc06a7e [aprofutil] Install the tool correctly (#16112)
* mono/mono@1848d78d60 [aotprof-tool] Initial import of AOT profiler tool (#15384)
* mono/mono@da0086e304 [2019-08] Add RenamedEvent* to FSW sources from CoreFX (#16756)
* mono/mono@0297b21b03 [msbuild][roslyn] Bump msbuild and roslyn to pull in new versions (#16768)
* mono/mono@40631e3b9e [2019-08] [aot] move method_addresses to data.rel.so section to avoid text relocations (#16751)
* mono/mono@68b77674e2 Vtable [i] can be null so this should be check before use it. Fixes#16712
* mono/mono@4a0b4f41ed [mini] publish global patches after JitInfo has been added
* mono/mono@7a1f63fde6 [debugger][android] It was not initialising seq_points on MonoCompile on Android, so when was compiling dynamic methods, seq_points wasn't created and we got the assert when try to single step.
Diff: 29b1ac19c9..70d6903053
* [tests] Add a fat macOS dylib for testing purposes.
Add a binary version of a fat macOS dylib (because we can't create one when we
need it since we can't create 32-bit slice anymore).
It was created like this (in tests/test-libraries):
$ cat test.m
int theUltimateAnswer ()
{
return 42;
}
$ /Applications/Xcode94.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang test.m -olibtest.i386.dylib -shared -isysroot /Applications/Xcode94.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -framework Foundation -framework CoreLocation -lz -arch i386
$ lipo -create libtest.i386.dylib .libs/macos/libtest.dylib -output libtest-fat.dylib
* [tests] Adjust XM tests to XM not having fat dylibs anymore.
* [tests] Adjust product tests to some libraries not being fat anymore.
* One more test fix.
It's the same hash as Xcode 11 GM 2 but it's cleaner to actually use `Xcode11.app`.
In addition: the device bots are looking for "GM" and "beta" in the Xcode name to run on either the stable or beta pool.
Sebastien Pouliot
Rolf Bjarne Kvinge
Bernhard Urban-Forster
Manuel de la Pena
Vũ Đức Tuyến
Alexander Köplinger
Vincent Dondain
Difegue
Alex Soto
monojenkins
Waleed Chaudhry
