* 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.
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.
* [AppKit] Add missing Accessibility protocols.
This commit adds a few protocols that were missing. It is interesting to
mention that there are two of the protocols that are decorated with
NS_PROTOCOL_REQUIRES_EXPLICIT_IMPLEMENTATION, as per Apple documentation
this means that:
'Unlike normal protocols, when you adopt one of the role-specific protocols,
Xcode may ask you to reimplement methods that have already been implemented
by one of your ancestors.
In order to ensure that your control returns accurate and useful information,
some methods are tagged with the NS_PROTOCOL_REQUIRES_EXPLICIT_IMPLEMENTATION
attribute. For these methods, you need to override your superclass’s
implementation with your own.
'
In this case, we need to add the methods from all the parent classes and
set them to be [Abstract] since they are required. Not all methods have
to be added ONLY the required ones.
fixes: https://github.com/xamarin/xamarin-macios/issues/7079
* Remove the new methods.
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.
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
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
* Drop the Xcode 9.4 dependency. (#7044)
* Drop the Xcode 9.4 dependency.
Also bump mono to get the removal of the mac32 binaries.
New commits in mono/mono:
* mono/mono@beb9a1b182 [sdks] Remove the mac32 build.
* mono/mono@747a919a06 [ci] Make ios/mac sdks archive URL more predictable
* mono/mono@114013096e [ci] Build iOS/Mac Mono sdks archive using Xcode 11
* mono/mono@10a24f3ea1 Implement WriteCore and ReadCore in DeflateStream
* mono/mono@a925846b1f [offsets-tool] Install clang into the user-specific python directory. (#16933)
* mono/mono@fe64a4765e [2019-06] Bump msbuild and sdk versions to 3.0.1xx latest (#16870)
* mono/mono@7293597b90 [corlib] Fix building nunit-lite twice (#16910)
* mono/mono@1648e88687 Rename bundle identifier for the various Mono.frameworks we create for Xamarin.iOS. Fixesxamarin/xamarin-macios#7005. (#16896)
* mono/mono@a6b5187d76 [metadata] Fix leaks when handling a few attributes (#16675) (#16851)
* mono/mono@7da9a041b3 [2019-06] Bump to mono/corefx@e79cf5b
* mono/mono@2b7050bdf3 [2019-06] Add RenamedEvent* to FSW sources from CoreFX (#16758)
* mono/mono@4f5ed502c6 [msbuild] pick up p4 versions
* mono/mono@f04ee2219d [2019-06][msbuid][roslyn] Bump msbuild and roslyn-binaries to pick up dotnet 3.0.100-p9 toolset
* mono/mono@6b4b99e571 Vtable [i] can be null so this should be check before use it. Fixes#16712
Diff: 7af64d1ebe..beb9a1b182
* [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.
* [tests] Don't treat an Xcode with the same major version number as old.
Fixes an issue in the MT0091 test, where it would fail on tvOS because the
test wanted to use an older Xcode, and we could end up returning Xcode 11.0
when the current Xcode is 11.1. Since the test depends on using the OS SDK as
it was designed for (technically using an OS SDK earlier than the latest), it
ended up failing because while the iOS SDK was bumped in Xcode 11.1, the tvOS
SDK was not.
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 );
^
Tests were failing because the manager was getting dispose and the
delegate was not. We ran into the failure because there was a device
close to the lab with the UUID that was being used.
The change uses a even more common UUID (heart monitor), which should
increase the chances to pick up a device and re-orgs the disposal of the
manager and the delegate.
This was confirmed with a BLE device, watchOS does not like us to try
and access it as a bluetooth device and is 'hacky'.
Fixes: https://github.com/xamarin/xamarin-macios/issues/7108
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
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.
Rolf Bjarne Kvinge
Vũ Đức Tuyến
monojenkins
Alexander Köplinger
Sebastien Pouliot
Vincent Dondain
Manuel de la Pena
Alex Soto
Matt Sylvia
Difegue
Bernhard Urban
