* [Mtouch] Make sure that the given SDK version and the iOS version do match.
We need to make sure that the iOS SDK and the iOS version do match the
ones present in Xcode.
* Add new variables to track the target version.
* Add method to get the target version.
* Modify mtouch to check agains the target framework rather than the
SDK.
This will allow to keep track of three independent things:
1. The SDK max version.
2. The Simulator max version.
3. The target version of the device.
This had to be added becuase 13.2 has targets to 13.2 but simulators for
13.3
Fixes: https://github.com/xamarin/xamarin-macios/issues/7705
* [registrar] Fixes NSString trampoline code generation in static registrar
Fixesxamarin/xamarin-macios#7733
This was introduced as a side effect of commit 8425129, we
used to generate `id foo` instead of the full block signature
in the trampoline code used by the static registrar, this is
the reason we never caught this condition before.
Added registrar test.
* Move tests to the appropiate test file
Co-authored-by: Alex Soto <alex@alexsoto.me>
* [registrar] Fixes NSString trampoline code generation in static registrar
Fixesxamarin/xamarin-macios#7733
This was introduced as a side effect of commit 8425129, we
used to generate `id foo` instead of the full block signature
in the trampoline code used by the static registrar, this is
the reason we never caught this condition before.
Added registrar test.
* Move tests to the appropiate test file
We need to make sure that the iOS SDK and the iOS version do match the
ones present in Xcode.
* Add new variables to track the target version.
* Add method to get the target version.
* Modify mtouch to check agains the target framework rather than the
SDK.
This will allow to keep track of three independent things:
1. The SDK max version.
2. The Simulator max version.
3. The target version of the device.
This had to be added becuase 13.2 has targets to 13.2 but simulators for
13.3
Fixes: https://github.com/xamarin/xamarin-macios/issues/7705
- https://github.com/xamarin/xamarin-macios/issues/5738
- There are a number of managed exceptions Apple can throw at you during
debugging, such as expanding a NSColor in the wrong colorspace
- Throwing a managed exception is a nicer debugging experience, and
during debug we don't care about any performance penality.
TL&DR
* re-apply the fix to cache.cs from https://github.com/xamarin/xamarin-macios/pull/7544
* which was reverted in https://github.com/xamarin/xamarin-macios/pull/7589
* since it regressed mscorlib/sim testing in xharness (for other reasons)
* Final part to fix https://github.com/xamarin/xamarin-macios/issues/7514
This was the ~night~ day before christmas... amd a tough nut to crack!
Thanksfully we had a good test case (inside #7514) and then xharness
regressed one test in consistent, reproducible manner.
xharness builds mscorlib tests twice (32 and 64 bits) even if it's a
fat application (could be reused). That should not be a huge problem
since the 2nd build should be identical and the cache should be (re)used.
An earlier attempt fixed this (comparison was true for the wrong
reasons [1]) but the fix did not end up with the same arguments !?! and
was reverted.
This is the diff between the first and second builds:
```diff
--- /Users/poupou/a.txt 2019-12-23 09:55:01.000000000 -0500
+++ /Users/poupou/b.txt 2019-12-23 09:55:01.000000000 -0500
@@ -182,5 +182,5 @@
-r=/Users/poupou/git/xamarin/xamarin-macios/builds/downloads/ios-release-Darwin-8f396bbb408b5758fccb8602030b9fa5293ce718/ios-bcl/monotouch/tests/Xunit.NetCore.Extensions.dll \
' --target-framework=Xamarin.iOS,v1.0' \
--root-assembly=/Users/poupou/git/xamarin/xamarin-macios/tests/xharness/tmp-test-dir/mscorlib/bin/mscorlib/iPhoneSimulator/Debug-unified/com.xamarin.bcltests.mscorlib.exe \
- ' -v -v -v -v' \
+ ' -v -v' \
@/Users/poupou/git/xamarin/xamarin-macios/tests/xharness/tmp-test-dir/mscorlib/obj/iPhoneSimulator/Debug/response-file.rsp \
```
Since they are not identical the cache is invalidated (which is normal,
cache-wise) and produce an output app that is incorrect (and crash
32bits).
Now there is code to ignore verbosity options (both `-v` and -q`) since
they will not affect what `mtouch` generates. However this was broken
because mtouch's response-file parser is quite basic and stricter the the
specification
spec: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/response-file-compiler-option
issue: https://github.com/xamarin/xamarin-macios/issues/7644
That failed in two different ways
1. note the extra space before the first `-v` in the diff (before the `'`
quote). That skipped the line.
2. there are multiple `-v` in the same line, again that make the
filtering skip the line.
*Unknowns*
It's too close to xmas/vacation so I might not find the reasons/issues
for the following, unanswered questions...
1. Why is the re-build app bundle failing at runtime when p/invoking ?
Something is not regenerated (symbol maps?) ?
2. Why xharness 2nd build has more verbosity than the first one (likely
harmless) ?
[1] the original cache.cs issue (prequel)
issue w/test case: https://github.com/xamarin/xamarin-macios/issues/7514
first attempt: https://github.com/xamarin/xamarin-macios/pull/7544
While incorrect the first attempt to fix `cache.cs` was a logical, if
not entirely complete, fix. Without it this is what we _currently_ cache:
```
/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/lib/mtouch/mtouch.exe \
```
and that does not include any of mtouch's arguments, that can change
between executions and (should) invalidate the cache.
In this case it means the cache is used (no difference) but this does
**not** parse the content of the **response file** which is obviously
wrong (and we do have code to process it).
On the original issue's test case this is what makes the difference
between using the same *old* nuget assembly after an update (and fail)
by itself and also because the updated framework was not copied (due
to the 2nd part of the bug report wrt `copyfile`).
OTOH re-using (incorrectly) the cache is what makes xharness's mscorlib
unit tests works right now :(
- https://devdiv.visualstudio.com/DevDiv/_workitems/edit/947932
- It turns out the linker in some cases can wrap expected exceptions in a outer exception. By drilling in we can produce better errors, again.
- Refactor pipeline exception handling to be shared between mmp/mtouch
Copying the framework could fail (error 260) and the failure was never
reported so the build succeeded - but without updating (completely) the
framework.
The exact reason it fails is unknown :( but we can recover from it by
deleting the target and copying (everything) back to the expected
(target) location.
Build logs will now indicate when this fails and will try to recover
before reporting a build error. Best case it works :) worse case we'll
be aware something is wrong (which is better than ignoring)
This is half the fix from https://github.com/xamarin/xamarin-macios/pull/7544
which was reverted due to the second half causing a regression (under
investigation).
Reference: https://github.com/xamarin/xamarin-macios/issues/7514 (partial fix)
It's possible for a nuget to have dependencies that will bring satellite
assemblies into a project.
When doing so the satellite assemblies are copied to the right output
(e.g. `Debug`) directory, so they work fine at runtime. However it's
not 100% fine at build time, e.g. msbuild won't detected them as
satellite assemblies.
Something similar happens with `mtouch` (and `mmp`) since the satellite
assemblies won't be found inside a (culture-named) subdirectory from the
original assembly location. In our case this means the assemblies won't
be copied into the .app bundle (since we don't run from `Debug`) and
localization won't work properly.
The solution is to check for both the (culture-named) subdirectories
from the assembly location (like before) and, if nothing is found, also
try to locate them in the _build_ (like `Debug`) directory - so if
something else (nuget or custom build scripts) tried to outsmart the
build logic then we'll still bring those satellite assemblies in the
app bundle we produce.
https://github.com/xamarin/xamarin-macios/issues/7113
The nice, repeatable test case from #7514 pointed out two issues
1. `cache.cs` ignored some changes
It looks like something changed (at some point) and the first _ignored_
line was the `@x.rsp` our response file - which should not be ignored.
This solved the build issue where updating the nuget should have
triggered a rebuild because
> /Users/poupou/.nuget/packages/skiasharp/1.68.0/lib/Xamarin.iOS/SkiaSharp.dll
and
> /Users/poupou/.nuget/packages/skiasharp/1.68.1/lib/Xamarin.iOS/SkiaSharp.dll
are different assemblies (but the same response file).
2. `copyfile` could fail silently
Copying the framework could fail (error 260) and the failure was never
reported so the build succeeded - but without updating (completely) the
framework.
The exact reason it fails is unknown :( but we can recover from it by
deleting the target and copying (everything) back to the expected
(target) location.
Build logs will now indicate when this fails and will try to recover
before reporting a build error. Best case it works :) worse case we'll
be aware something is wrong (which is better than ignoring)
ref: https://github.com/xamarin/xamarin-macios/issues/7514
* Do not call `Marshal.GetLastWin32Error` instead the callback
as the `SetLastError` logic has yet to be executed so we get a bogus
`260` value...
Instead we call it after the `copyfile` call returns but, at this stage,
the callback (i.e. **us**) signaled an error so what we get back (`17`)
is not very helpful - as we aborted (Quit) the logic when copying a file
that existed.
```c
#define EEXIST 17 /* File exists */
```
from Console logs
```
default 14:23:54.771292-0500 mono64 Cannot make directory /Users/poupou/Projects/gh7514/gh7514/bin/iPhoneSimulator/Debug/gh7514.app/Frameworks/libSkiaSharp.framework: File exists
default 14:23:54.771620-0500 mono64 Cannot make directory /Users/poupou/Projects/gh7514/gh7514/bin/iPhoneSimulator/Debug/gh7514.app/Frameworks/libSkiaSharp.framework/_CodeSignature: File exists
default 14:23:54.771850-0500 mono64 open on /Users/poupou/Projects/gh7514/gh7514/bin/iPhoneSimulator/Debug/gh7514.app/Frameworks/libSkiaSharp.framework/_CodeSignature/CodeResources: File exists
```
`copyfile.c` source code (might not be the latest) can be seen from
https://opensource.apple.com/source/copyfile/copyfile-42/copyfile.c
```c
if (mkdir(s->dst, mode) == -1) {
if (errno != EEXIST || (s->flags & COPYFILE_EXCL)) {
copyfile_warn("Cannot make directory %s", s->dst);
```
so `mkdir` fails - but not because of `EEXIST` and from `copyfile.h`
we see that `EXCL` exists but it's not using (or even defined) in our
bindings.
```c
#define COPYFILE_EXCL (1<<17) /* fail if destination exists */
```
So sadly the `Err` condition (inside the callback) does not give us more
detail about the error itself.
Turn older #7165 prototype into an experimental feature. It can be
enabled by adding `--optimize=experimental-xforms-product-type` to the
**Additional mtouch arguments** of the project.
ref: https://github.com/xamarin/xamarin-macios/pull/7165
Turn older #7165 prototype into an experimental feature. It can be
enabled by adding `--optimize=experimental-xforms-product-type` to the
**Additional mtouch arguments** of the project.
ref: https://github.com/xamarin/xamarin-macios/pull/7165
The latest SDK version and the latest OS version does not necessarily have to
match (for instance the iOS 13.2 SDK can support both iOS 13.2 and iOS 13.3),
so keep track of them separately.
Also use the latest OS version to determine which simulator to run, instead of
the latest SDK version (Xcode 11.3 ships with the iOS 13.2 SDK but only has an
iOS 13.3 simulator, not an iOS 13.2 simulator).
Fixes https://github.com/xamarin/maccore/issues/2066.
* Add bindings for NSXpcConnection and related types
* Re-add accidentally deleted file
* Typo fix
* Add NSXpcInterface.CreateForType()
* Add MethodInfo-taking overloads to NSXpcInterface
* Add null check
* Mark methods with wrappers as internal
Also fixed a formatting bug that I didn't catch earlier.
* Change NSXPCProxyCreating methods to be strongly typed
I got rid of the NSXpcProxyCreating interface in this change,
because its only user was NSXpcConnection, and I needed to
inline the protocol methods into the class definition so I
could mark them as [Internal].
* Add missing casts
* Add NSXpcConnectionOptions enum
* Convert NSXpcConnection constructor to use new enum
* Remove now-unneeded manual constructor
* Fix bgen warning
* Typo fix
* Fix selector
* Remove incorrect use of BindAsAttribute
Per the docs, this only works for enums backed
by NSNumber and NSValue, not for enums
passed directly as integers.
* Fix duplicated selector errors
* Throw ArgumentException instead of InvalidOperationException
* Extend AppExtension targets to produce XPC services
Rather than create an entirely new set of targets
(that would require VS and VSMac updates to properly
consume), I have decided to use the existing AppExtension
build targets to produce XPC services as well. All the
user must do is set the $(IsXPCService) property to true in
their project file, and the targets will do The Right Thing™.
Note that this support is Mac-only for now; I may need a bit
of help adjusting them to work on for iOS/watchOS/tvOS, as I
am not as familiar with those platforms.
* Copy XPC service bundles into the correct location
* Move IsXPCService property definition to props file
* Don't pass /extension to mmp for XPC service targets
This would cause the XPC service binary to
be linked incorrectly.
* Add NSXpcConnection/NSXpcInterface.cs files to the build
* Fix build
* Fix build
* Add required type parameter requirements
* Fix type parameter requirements
* Fix return type
* Fix return type of NSXpcInterface.CreateForProtocol ()
* Take ownership of the returned object types
* Adjust XPC service mmp invocation
I need to link the XPC service bundle as if it is an app extension, but
I must not use xamarin_mac_extension_main. I added a new flag to make
this possible.
* Change mmp to correctly construct XPC service bundle
* Set the MonoBundleExecutable Info.plist key for XPC services
* Use the runtime to get the protocol
* Make NSXpcInterface.CreateForProtocol() public
The static registrar must be used for Cocoa to accept the protocol
as a valid XPC interface, but that then seems to break resolving
the protocol from the type. I must therefore hard-code the protocol
name in my code, and that requires I make this constructor public.
* Add XpcInterfaceAttribute
See the doc comment in XpcInterfaceAttribute.cs for why
this type is required. The referenced mmp optimizations
will be added in future commits.
* Add XpcInterfaceAttribute to generator build
* Add support for XpcInterfaceAttribute to the generator
* Force static generation of protocols decorated with XpcInterfaceAttribute
* Change how static registrar translates block parameters
Previously, they would always be marshalled as "id".
This would throw off the XPC subsystem, which parses
the block signature to determine the communication
protocol.
* Undo whitespace noise
* Remove unneeded casts
* Add trailing comma
* Use HasAttribute instead of GetCustomAttribute
* Fix style issues
* Bind NSXpcConnection.auditSessionIdentifier
* Address naming feedback
* Make Get/SetAllowedClasses public
IMHO, passing the selector as a string is just as
usable as passing a MethodInfo, and is also less
verbose if you copy/paste the selector string
from the ExportAttribute. There is no reason why
we cannot have both overloads be public.
* Update overload names to match
* Update more overload names to match
* Make mmp --xpc imply --extension
* Reformat if statement
* Fix build
* Conditionalize creation of PlugIns and XPCServices directories
* Add AutoGeneratedName
Co-Authored-By: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Get rid of ProtocolizeAttribute
* Update availability attributes to please xharness
I actually think xharness is wrong here, since the
NSXPCConnection header lists these types as being
available starting in macOS 10.8.
* Update sharpie ignore files to reflect changes
This should fix the xtro-sharpie test failures CI has been reporting.
* Fix MM4105 error generation
* Adjust error message in test to match mmp
I had to change the error text slightly, because the type of the parameter
cannot be determined where the error is thrown anymore. However, the newer
exception message IMO is just as clear.
* Make exception message match test exactly
* Remove outdated copyright header text
* Remove more outdated copyright header text
* Revert changes to MM4105 error generation
I have a more elegant way of fixing this test now.
* Return "id" if Invoke method cannot be found
This fixes the MM4105 error unit test,
without requiring modification to that test.
* Remove redundant availability attributes
* Add DesignatedInitializerAttribute
* Re-add required code to macOS-Foundation.ignore
* Put DesignatedInitializer on the right constructor
* Update xtro-sharpie ignore files
Apple decided to expose most (but not all) `CIFilter` using protocols
(instead of weakly named dictionaries). Most of this maps well with
our strong bindings but there are cases where we:
* missing some properties (easy, there were added); or
* used a different types [1] and that requires new members / obsoletion
A few other API were also added in Xcode 11 (nothing in 11.1 or 11.2) and
included in this PR.
New introspection tests were also added to minimize the risk that
the API and generator changes produced incorrect code. This lead
to the finding of some missing API (in particular `Output*` properties)
that were added.
[1] Often ours are better (using `float` for a `bool` value is not
optimal) but we do not have `[BindAs]` for protocols :( to _fix_ them
Note: this replace draft PR https://github.com/xamarin/xamarin-macios/pull/7120 but it's has quite a bit of changes in filter generation (inlining protocols) and that affected bindings too.
* Implement a different escaping/quoting algorithm for arguments to System.Diagnostics.Process.
mono changed how quotes should be escaped when passed to
System.Diagnostic.Process, so we need to change accordingly.
The main difference is that single quotes don't have to be escaped anymore.
This solves problems like this:
System.ComponentModel.Win32Exception : ApplicationName='nuget', CommandLine='restore '/Users/vsts/agent/2.158.0/work/1/s/tests/sampletester/bin/Debug/repositories/ios-samples/WorkingWithTables/Part 3 - Customizing a Table\'s appearance/3 - CellCustomTable/CellCustomTable.sln' -Verbosity detailed -SolutionDir '/Users/vsts/agent/2.158.0/work/1/s/tests/sampletester/bin/Debug/repositories/ios-samples/WorkingWithTables/Part 3 - Customizing a Table\'s appearance/3 - CellCustomTable'', CurrentDirectory='/Users/vsts/agent/2.158.0/work/1/s/tests/sampletester/bin/Debug/repositories', Native error= Cannot find the specified file
at System.Diagnostics.Process.StartWithCreateProcess (System.Diagnostics.ProcessStartInfo startInfo) [0x0029f] in /Users/builder/jenkins/workspace/build-package-osx-mono/2019-08/external/bockbuild/builds/mono-x64/mcs/class/System/System.Diagnostics/Process.cs:778
ref: https://github.com/mono/mono/pull/15047
* Rework process arguments to pass arrays/lists around instead of quoted strings.
And then only convert to a string at the very end when we create the Process
instance.
In the future there will be a ProcessStartInfo.ArgumentList property we can
use to give the original array/list of arguments directly to the BCL so that
we can avoid quoting at all. These changes gets us almost all the way there
already (except that the ArgumentList property isn't available quite yet).
We also have to bump to target framework version v4.7.2 from v4.5 in several
places because of 'Array.Empty<T> ()' which is now used in more places.
* Parse linker flags from LinkWith attributes.
* [sampletester] Bump to v4.7.2 for Array.Empty<T> ().
* Fix typo.
* Rename GetVerbosity -> AddVerbosity.
* Remove unnecessary string interpolation.
* Remove unused variable.
* [mtouch] Simplify code a bit.
* Use implicitly typed arrays.
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
```
* 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.
* 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.
* [registrar] Report a warning when the registrar export an abstract INativeObject type to Objective-C.
Exporting abstract types to Objective-C can lead to problems when at runtime
we're asked to create an instance of such a type (which we can't), so warn
when this happens.
This would have caught #6655, and the problems explained in #4969 as well.
Since this may trigger for code that's currently working fine, I'm making it a
warning instead of an error (which means adding some extra code to be able to
easily report warnings from the generator code).
* Don't assume a TypeReference can be successfully resolved every time.
Included changes are:
* New Cecil API in 2019-08
* Permit new symbols from networkable AOT profiler in symbols test
* Bump Mono to include fix for zlib linking, and new Cecil API
* We need to link against zlib now, if using libmono.a
* [Tests] Ignore memory hungry tests in old devices. (#6913)
* Ignore certain tests that use too many resources in old devices.
* Add missing tests that use too much memory on 32b devices.
* Add a dummy x86_64 slice to all our native libraries that don't have one. (#6848)
Apple's notarization tool has a bug where they incorrectly flag Mach-O
binaries without an x86_64 slice, so make sure all our libraries have one.
* Jenkinsfile notarization (#6869)
* Add in notarization script for xamarin.mac/xamarin.iOS
* Flatten the list to get rid of the braces
* Add in keychain password
* Add login.keychain back in to access codesigning certificates
* Always sign pkgs, upload notarized copies
* Enable ios notarization and make notarized pkgs public
* Make notarization non-fatal
* Publish GH statuses for notarized PKGs
* Don't forget to declare URI variables for notarized pkgs
* report proper package links
* [jenkins] Improve package reporting.
* Use dummy function name which our tests won't complain about.
* Add a dummy x86_64 slice to all our native libraries that don't have one. (#6848)
Apple's notarization tool has a bug where they incorrectly flag Mach-O
binaries without an x86_64 slice, so make sure all our libraries have one.
* Jenkinsfile notarization (#6869)
* Add in notarization script for xamarin.mac/xamarin.iOS
* Flatten the list to get rid of the braces
* Add in keychain password
* Add login.keychain back in to access codesigning certificates
* Always sign pkgs, upload notarized copies
* Enable ios notarization and make notarized pkgs public
* Make notarization non-fatal
* Publish GH statuses for notarized PKGs
* Don't forget to declare URI variables for notarized pkgs
* report proper package links
* [jenkins] Improve package reporting.
* Use dummy function name which our tests won't complain about.
* Build native code with -std=c++14.
Apple's headers now require -std=c++14 to compile their headers in C++ mode.
This fixes a compile error that would occur with the PhotosUI framework when
compiling code for C++.
* [mmp] Use -std=c++14 when compiling.
* Fix command line output.
* [mmp] Add all source files at the end, so they all get the -x clang argument applied.
* Limit when using c++14 in mtouch according to language.
Also limit the output from the native compiler, so that we don't overload the
IDEs with output if the native compiler produces tens of thousands of errors.
Fixes https://github.com/xamarin/xamarin-macios/issues/6526.
New framework - but it includes some of iOS API that were previously in
QuickLook.framework. Types were moved but remains in the old namespace
until `XAMCORE_4_0` is defined.
* [WatchKit] Remove this framework for iOS while keeping backwards compatibility. Fixes#6492.
* Copy all generated sources and modify them to throw PlatformNotSupported exceptions.
* Adjust some existing source code to also throw PlatformNotSupported exceptions.
* Sprinkle Obsolete attributes generously.
* Stop generating code for the WatchKit framework for iOS.
Fixes https://github.com/xamarin/xamarin-macios/issues/6492.
* [introspection] Adjust test.
* [mtouch] Don't link with WatchKit, and show a warning if we detect code that want to use WatchKit.
* [xtro] Remove WatchKit for iOS.
* [introspection] Don't check obsoleted NSString fields for null.
There's probably a reason the field was obsoleted.
* [introspection] Add exception for the WatchKit framework.
* [xtro] Ignore obsolete enums.
There's probably a reason they're obsoleted.
In particular it solves a confusion between WKWebKit.WKErrorCode and
WatchKit.WKErrorCode: for iOS, the latter is obsoleted, and this way we always
process the former instead.
* [mtouch] Adjust wording for MT4178 to be more accurate.
* [WatchKit] Make more API obsolete/hidden.
Two classes managed to slip past the first time.
* [tests] Adjust test after WatchKit removal.
Moved some code from uikit.cs since the type moved a while ago. That
ease code sharing with macOS (XM) but it stays into the UIKit namespace
(for XI) until `XAMCORE_4_0` to ensure binary compatibility.
This includes:
* 32-bit version of Xamarin.Mac.dll and OpenTK.dll
* XamMac.dll and XamMac.CFNetwork.dll
* 32-bit versions of the runtime libraries (libxammac.a and friends).
* 32-bit version of the partial static library for Xamarin.Mac.
* Classic support in the generator.
We still ship a few Classic files so that Visual Studio for Mac continue to detect that Xamarin.Mac is installed (otherwise VSfM won't open Classic projects, which makes it impossible to use the migration wizard).
This makes our build slightly faster.
Partial fix for #6300.
* adding Speech
* Style changes and fixed copyright
* fixing requested changes
* adding spacing to make less red in diff
* adding [DisableDefaultCtor] to SFSpeechRecognitionResult and SFTranscription
* Update src/speech.cs
Co-Authored-By: Alex Soto <alex@alexsoto.me>
* Update src/speech.cs
Co-Authored-By: Alex Soto <alex@alexsoto.me>
* Update src/speech.cs
Co-Authored-By: Alex Soto <alex@alexsoto.me>
* Adding PencilKit to the src
* forgot the mac constants
* adding PencilKit and fixed whitespace
* removing whitespace
* removed mac capabilities and added ignore for PencilKit.todo
* removed newline
* added the iOS-PencilKit.ignore file
* removed pencilkit.todo
* adding DesignatedDefaultCtor
No change in beta 2
This enable PushKit on watchOS and macOS.
Availability macros suggest this is available on tvOS 13 but the
headers are not in the tvOS SDK (at least in beta 2)
No change in beta 2
This enable some API in macOS. Headers are now present and some types are
marked as unavailable on macOS - but, sadly, nothing got marked as new
for 10.15 :|
* adding Sound Analysis
* set up error domain and added CMTimeRange for all platforms except watch
* removed whitespaces
* removed more whitespaces
* edited framework files and constants. Changed header names and added todo files
* Apply feedback
* fixing head and skipping functions with class issues
* fixing spacing-tab issues
* [tests] Minor refactor to get better Xcode version parsing.
* Rename Configuration.XcodeVersion to XcodeVersionString.
* Add Configuration.XcodeVersion a parsed Version instane of XcodeString.
* [tests] Ignore all 'MT0099: Not linking with WatchKit because Xcode 11 beta 1' warnings in tests.
* [tests] Adjust min OS version tests for Xcode 11b1.
* [tests] Adjust tests for changes in 'nm' output.
* [tests] Adjust tests for name changes in Clang.
* [tests] Adjust tests for changes in ld warning format.
* [msbuild] 'metal' and 'metallib' aren't in PATH anymore, so use xcrun to execute them.
* [msbuild] Fix DevicePlatformBinDir for the Metal and MetalLib targets on iOS.
Also set the SDKROOT variable, otherwise metal and metallib don't work
properly, and revert the previous attempt at a fix (use xcrun).
* [tests] Simplify version parsing code to not version parse anymore.
* [tests] Add FIXME for once Apple fixes the WatchKit disappearance.
* The Photos headers are broken when building in C++ mode.
* The PhotosUI headers include the Photos header, so those don't work either.
* The WatchKit framework just isn't there at all.
So far this only applies to `QTKit`...
XM will now, by default, avoid natively link with QTKit unless it's
instructed to so explicitly using `--link-prohibited-frameworks`
ref: https://github.com/xamarin/xamarin-macios/issues/6039
This allows the optimization to be disabled in cases where one, or
many, a custom attribute(s) are required by the application at runtime.
While not ideal disabling this single step is much better than disabling
linking for the whole application.
A better approach is described in https://github.com/xamarin/xamarin-macios/issues/6048
but this configuration optimization makes sense independently of it.
Fix https://github.com/xamarin/xamarin-macios/issues/3655
This allows the optimization to be disabled in cases where one, or
many, a custom attribute(s) are required by the application at runtime.
While not ideal disabling this single step is much better than disabling
linking for the whole application.
A better approach is described in https://github.com/xamarin/xamarin-macios/issues/6048
but this configuration optimization makes sense independently of it.
Fix https://github.com/xamarin/xamarin-macios/issues/3655
An mlaunch fix in master required a code change in xamarin-macios; when
backporting this mlaunch fix to d16-2 the corresponding xamarin-macios fix was
not, causing the build to break.
Fixes this:
[...]
Build FAILED.
"/Users/builder/jenkins/workspace/xamarin-macios/maccore/tools/mlaunch/Xamarin.Hosting/Xamarin.Hosting.sln" (default target) (1) ->
"/Users/builder/jenkins/workspace/xamarin-macios/maccore/tools/mlaunch/Xamarin.Hosting/Xamarin.Hosting.csproj" (default target) (2) ->
(CoreCompile target) ->
/Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tools/common/MachO.cs(10,15): error CS0234: The type or namespace name 'Bundler' does not exist in the namespace 'Xamarin' (are you missing an assembly reference?) [/Users/builder/jenkins/workspace/xamarin-macios/maccore/tools/mlaunch/Xamarin.Hosting/Xamarin.Hosting.csproj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:03.63
make[3]: *** [Xamarin.Hosting/Xamarin.Launcher/bin/Debug/mlaunch.app] Error 1
The arm64_32 slice for watchOS apps will always use the 'unified' mode, while
the armv7k can be both 'unified' and 'compat' depending on the deployment
target, so we need to keep track of this per Target.
This PR does not change anything related to arm64_32, that will come in a
later PR.
The arm64_32 slice for watchOS apps will always use the 'unified' mode, while
the armv7k can be both 'unified' and 'compat' depending on the deployment
target, so we need to keep track of this per Target.
This PR does not change anything related to arm64_32, that will come in a
later PR.
* [mtouch/mmp] Split out the RunCommand[Async] methods to a separate file so that the generator can reuse more easily.
* [generator] Show proper errors when failing to compile something.
* Fix grammar
* [runtime] Add an inner exception parameter to Runtime.CreateProductException.
This allows us to simplify code by using inner (and outer) exceptions as
a means to provide information instead of passing extra information
around in order to create decent exceptions.
One example is how we pass the selector and method name to the method
that converts from a native id to a managed NSObject instance: passing
this information is not necessary anymore if we can use two exceptions,
one for the failure to convert from an id to a NSObject instance,
wrapped in a second that tells which method/selector call ran into this
conversion problem.
* [runtime] Throw better exceptions when the dynamic registrar can't marshal something.
* [runtime] Throw a better exception when something goes wrong when trying to marshal a return value.
* [runtime] Use inner exceptions to convey failure information instead of trying to create a single exception with all we know.
* Fix merge problem.
* [registrar] Make a copy of the static registrar for Xamarin.Mac/Classic.
Make a copy of the static registrar for Xamarin.Mac/Classic, one which is
compatible with the binary artifacts we ship for Xamarin.Mac/Classic
(libxammac, XamMac.dll).
This way the static registrar can evolve in the future, without breaking
Xamarin.Mac/Classic.
* [runtime] Make a copy of the runtime headers too.
* Update comment.
* [mmp] Delay creating a Target instance until we know if we're a Classic or Unified app.
Otherwise the wrong static registrar might be created.
According to Rolf it's fine to always add since the native linker will
figure out if it's really needed and so customers don't need to do
anything when using -all_load.
* [Foundation] Add an NSArray.FromNSObjects overload that can take an array of INativeObjects.
* [runtime] Use mono_array_setref instead of mono_array_set.
Otherwise the GC won't know about the assignment, and the assigned value can
be freed if it's no longer referenced anywhere else.
Some optimizations are not safe to apply when dynamically loading code
at runtime. This is not possible when ahead-of-time (AOT) compilation
is used, so those options were always enabled in the past. The
interpreter is changing the situation so those optimizations are now
disabled, when the interpreter is enabled.
The disabled optimizations are:
* 'remove-dynamic-registrar' when using the interpreter
This avoid the following exception when unknown (at build time) code
tries to register (at runtime)
```
Unhandled Exception:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> ObjCRuntime.RuntimeException: Can't register the class SubclassDemo.CustomView when the dynamic registrar has been linked away.
```
* 'inline-isdirectbinding' when using the interpreter
This avoid crashing (at runtime) when types are subclasses by the
interpreter (code unknown to `mtouch` at build time).
* 'register-protocols' when the interpreter is enabled
Dynamically loaded code can include protocols. When the optimization is
enabled then they won't be registered and won't work as expected.
Note: It is possible to re-enable the optimization(s), either one or all,
if the interpreter is not used to dynamically load code at runtime.
E.g. `MetalPerformanceShaders` is unusable in 10.3.1 on the simulator so
trying to build with the static registrar cause simlauncher to be rebuilt
with a **strong** (and not _weak_) reference to the framework. This cause
a crash then the application start
```
Dyld Error Message:
Library not loaded: /System/Library/Frameworks/MetalPerformanceShaders.framework/MetalPerformanceShaders
Referenced from: /Users/USER/Library/Developer/CoreSimulator/Devices/95679F95-CCE7-4733-8376-35E91E97039C/data/Containers/Bundle/Application/0F665B2D-ADAC-4CA0-BD04-33E968B3F268/FailerApp.app/FailerApp
Reason: no suitable image found. Did find:
/System/Library/Frameworks/MetalPerformanceShaders.framework/MetalPerformanceShaders: mach-o, but not built for iOS simulator
```
ref: https://github.com/xamarin/xamarin-macios/issues/5753
document it and adjust the optimization tests.
This allows the optimization to be:
* disabled (if ever needed) on fully AOT'ed applications
* re-enabled for the interpreter (at your own risk)
* MachO.cs: Support reading LC_BUILD_VERSION
Newer SDKs set this instead of LC_VERSION_MIN_*
* MachO.cs: Add support for reading Mach-O files inside ar archives.
* [tests] Augment ProductTests.MinOSVersion to test static libraries as well.
* Adjust enum field names to match our naming scheme.
Also change output to use the full path to files as nodes, instead of just the
filename, and instead use a label to set what's shown to just the filename.
This makes the graph correct when we have multiple files with the same name,
but different paths.
We need our 32-bit and 64-bit assemblies to be identical so that we can avoid
duplicating the .dll in fat apps.
One difference used to be that the .dll contained the full path to the
corresponding .pdb ([1]), but we changed cecil to only write the filename
([2]). Unfortunately this change breaks something else, so it has to be
reverted ([3]).
This implements a different solution: we provide a custom symbol writer to
Cecil, which only writes the filename of the pdb in the .dll, not the full
path.
[1]: https://bugzilla.xamarin.com/show_bug.cgi?id=54578
[2]: https://github.com/jbevain/cecil/issues/372
[3]: https://github.com/jbevain/cecil/pull/554
(cherry picked from commit 53874c863996656eaba43a5582731b93eb6f53b7)
# Conflicts:
# tools/mtouch/mtouch.csproj
* Add a Runtime.IsARM64CallingConvention property.
Determining whether we should use the ARM64 calling convention in P/Invokes
gets more complicated with ARM64_32 (which for our purposes is a 32-bit
architecture).
So add a property on the Runtime class to avoid code duplication, and teach
the linker to optimize any calls to this property to a constant value whenever
possible (and the method is marked as optimizable).
Also change our code to use this new property, and make the corresponding
methods optimizable.
Some shuffling in mmp was required, which meant a little bit more code is now
shared between mtouch and mmp.
* Coding style.
* Test tweaks.
* Improve comment.
* Document new optimization
* Move ILReader to shared linker test code location.
* Disable inlining on armv7k.
* Change IsARM64CallingConvention to a read-only field.
We can give the AOT compiler a constant value for a read-only field, so that
the AOT compiler optimizes away the call to the field by using the constant
value.
This commit does not implement this change for the AOT compiler, but using a
read-only field makes it easy to implement it in the future.
* [linker] Remove non-bitcode compatible code, and show a warning.
Remove code not currently compatible with bitcode and replace it with an
exception instead (otherwise we'll assert at runtime).
Also show a warning when we detect this.
This is quite helpful when looking at watch device test runs to filter out
failures we already know about.
This fixes point #2 in #4763.
* Improve documentation.
* Simplify linker code by using a substep.
* Fix whitespace issues.
* Improve reporting.
* Add support for reporting more than one MT2105 at the same time when making
the errors instead of warnings.
* Only report MT2105 for methods that haven't been linked away.
* Format the error message nicer for properties.
* Tweak a bit for warning tests to pass.
* Use ExceptionalSubStep to provide better error information.
* Adjust where linker warnings/errors are reported from to avoid a NullReferenceException.
This is usually not a problem, because these variables are already set when
running from the command-line or xharness. However, it shows up when running
tests directly from VSfM.
Deserialize cached Objective-C class symbols to match how the objects looked
before serialization. This means storing the Objective-C class name in the
Symbol.ObjectiveCName field, and not the Symbol.Name field.
Fixes https://github.com/xamarin/xamarin-macios/issues/5467.
objc_msgSend*_stret doesn't exist on arm64, so trying to call these functions
in our generated P/Invoke wrappers will result in a clang error:
[...]/pinvokes.m:180:69: error: 'objc_msgSend_stret' is unavailable: not available in arm64 (TaskId:243)
So instead generate a call to throw an EntryPointNotFoundException (which is
exactly what would happen if we didn't generate the P/Invoke wrapper).
Fixes https://github.com/xamarin/xamarin-macios/issues/5183.