* 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.
- Existing binding projects embed the native libraries within the assembly as managed resource
- This does not scale well and has performance implications
- This PR creates a new property, NoBindingEmbedding which when true processes the building and consumption of binding projects differently.
- Existing binding projects are not affected, they will continue as is
- I've written a full XM test suite and ported a subset to iOS. Since iOS only supports checked in projects, and I didn't want to make the existing situation worse by adding more, I only wrote tests that could use the existing test projects.
-When we complete some form of msbuild testing reform, we'll revisit these tests.
- Remove two files in MyiOSFrameworkBinding that are not used (we use copies elsewhere)
- Remove unnecessary sleep and fix broken touch command
- Output failing test log to console instead of test output
- VSfM does not handle thousands of lines of test failure message well
- Add ability to generate binding projects with LinkWith
Cloning directories is *much* faster than copying, so make sure we clone when
possible.
This will still fall back to copying if it the file system doesn't support
cloning.
Share all the code to find and verify Xcode between mtouch and mmp.
Also print out the actual product version when logging which Xcode was used
(to make it easier to detect if a beta version is in use).
I'm not sure why we have an entry in our list of frameworks claiming that
iTunesLibrary was introduced in macOS 10.9, when we didn't have any bindings
for the library back then.
In any case we also have an entry for iTunesLibrary in our list of frameworks
claiming that iTunesLibrary was introduced in macOS 10.14.
I looked at some of Apple's documentation for the types in iTunesLibrary, and
they all claim to be introduced in macOS 10.13 [2].
And to make matters even more interesting, Apple's documentation for the
framework itself states the library is in
/Library/Frameworks/iTunesLibrary.framework, and ships with iTunes 11.0+ [1]
(which is introduced in 2012).
Then I looked at a macOS 10.14 machine, and the framework is available at
/System/Library/Frameworks/iTunesLibrary.framework, and
/Library/Frameworks/iTunesLibrary.framework is just a symlink there
(/System/Library/Frameworks/iTunesLibrary.framework does not exist on my macOS
10.13 machines, while /Library/Frameworks/iTunesLibrary.framework does). From
this I conclude that the framework was converted into a
system framework in macOS 10.14, and as such our claim that the framework was
introduced in 10.14 is at least somewhat right.
So treat iTunesLibrary as any other framework introduced in macOS 10.14, and
remove our (duplicated) framework entry for 10.9 (for which we didn't have any
bindings anyway).
Also fix the path to the framework, I'm wonder how this got past our tests in
the first place.
[1] https://developer.apple.com/documentation/ituneslibrary: "... located at /Library/Frameworks/iTunesLibrary.framework ... The iTunes Library framework is available to users running iTunes v11.0 or above."
[2] https://developer.apple.com/documentation/ituneslibrary/itlibrary?language=objc
* Refactor type map to have a separate flag field for each type instead of magic location in the array.
Refactor the type map to have a separate flag field for each type instead of a
magic location in the array. This simplifies some code, but also allows us to
introduce more flags in the future (which becomes increasingly complex if the
location in the array is to determine yet another value).
This has neglible performance impacts.
* Add a UserType flag for registered types, and use it to improve the performance for is_user_type.
Reflection in the Objective-C runtime is apparently quite slow, so try to
avoid it by computing the information we need for determining whether a
particular Objective-C type represents a user type or not in the static
registrar.
We store this information in a flag for the type in question in the type map,
and use a binary search to search the type map when needed.
This provides a significant improvement, in particular in the dontlink
scenario (probably because there are many more Objective-C types in the app,
which made Objective-C reflection slow). In fact, it somehow made the dontlink
scenario so fast that it's faster than the linkall scenario (which also
improved, but not nearly as much). While quite inexplicable, it's a consistent
result I've seen over multiple test runs.
Numbers
=======
Test case: 004283d7b6
Fix 1 refers to PR #5009.
Fix 2 refers to PR #5013.
Fix 3 refers to PR #5016.
Fix 4 is this fix.
iPad Air 2
----------
| Configuration | Before | After fix 1 | After fix 2 | After fix 3 | After fix 4 | Improvement from fix 3 to fix 4 | Cumulative improvement |
| ------------------- | ------ | ----------: | -----------: | -----------: | -----------: | ------------------------------: | ---------------------: |
| Release (link all) | 477 ms | 481 ms | 224 ms | 172 ms | 148 ms | 24 ms (14%) | 329 ms (69%) |
| Release (dont link) | 738 ms | 656 ms | 377 ms | 201 ms | 146 ms | 55 ms (27%) | 592 ms (80%) |
iPhone X
--------
| Configuration | Before | After fix 1 | After fix 2 | After fix 3 | After fix 4 | Improvement from fix 3 to fix 4 | Cumulative improvement |
| ------------------- | ------ | ----------: | -----------: | -----------: | -----------: | ------------------------------: | ---------------------: |
| Release (link all) | 98 ms | 99 ms | 42 ms | 31 ms | 29 ms | 2 ms ( 6%) | 69 ms (70%) |
| Release (dont link) | 197 ms | 153 ms | 91 ms | 43 ms | 28 ms | 15 ms (35%) | 169 ms (86%) |
When linking all assemblies, the type map has 24 entries, and when not linking
at all it has 2993 entries.
This is part 4 (the last) of multiple fixes for #4936.
The total speed-up is 69-86% (3-7x faster).
Our type map has two sections: first come all the wrapper types, then all the
custom types. This means we need to sort these two sections separately, since
code elsewhere depends on this split in order to determine if a type is a
custom type or not.
We also need a minor modification in the array of skipped types, since it
contained indexes into the type map, which won't be valid after is has been
sorted. Instead store a type reference for the actual type in the array, and
use that to search the type map for the corresponding Class. This is a little
bit slower, but the results are cached in a dictionary, so it'll only happen
once for each type.
The performance is slightly slower when the type map has very few entries, but
that is repaid many times over when the number of entries go up.
Numbers
=======
Test case: 004283d7b6
iPad Air 2
----------
| Configuration | Before | After | Improvement |
| ------------------- | ------ | ------ | ------------: |
| Release (link all) | 477 ms | 481 ms | -4 ms (-0,8%) |
| Release (dont link) | 738 ms | 656 ms | 82 ms (11%) |
iPhone X
--------
| Configuration | Before | After | Improvement |
| ------------------- | ------ | ------ | ----------: |
| Release (link all) | 98 ms | 99 ms | -1 ms (-1%) |
| Release (dont link) | 197 ms | 153 ms | 44 ms (22%) |
When linking all assemblies, the type map has 24 entries, and when not linking
at all it has 2993 entries.
This is part 1 of multiple fixes for #4936.
* Bump to mono:2018-06
* Bump mono
* Updates compression to work with the public span
* Bump mono
* Fixes pointer check logic in Deflater
* Bump mono
* Fixes pointer check logic in Deflater
* Bump mono
* Bump Mono
* [runtime] always use `mono_jit_set_aot_mode` (#4491)
`mono_jit_set_aot_only` is deprecated and accidentally broke with
https://github.com/mono/mono/pull/7887
This should fix device tests with `mono-2018-06`
* Testing with Zoltan's patch
* Include libmono-system-native on Xamarin.Mac
* Bump Mono
Commit list for mono/mono:
* mono/mono@7bcda192a0 Bump llvm to release_60/fc854b8ec5873d294b80afa3e6cf6a88c5c48886. (#9786). (#9804)
* mono/mono@23e95ec7ad Apply F# portable pdb debug fix for pinvokes & bump (#9797)
* mono/mono@295f6d32af [2018-06] [MacOS] On Mac, use the copyfile API to copy files (#9696)
Diff: 7d5f4b6136...7bcda192a0
* Revert 4bacab3d5c, it doesn't fix the ios aot problems.
* Bump mono
* [tests] Adjust the MT0137 test for mcs change in behavior.
Starting with mono 5.16 mcs will now add assembly references when the assembly
is only used in attributes (this was already the case for csc in both 5.14 and
5.16, so it seems to be a compatibility change).
Adjust the MT0137 test accordingly.
* [msbuild] Fix parsing of json parser errors to handle trailing periods in the error message.
Fixes this test:
1) Test Failure : Xamarin.iOS.Tasks.Bug60536.TestACToolTaskCatchesJsonException
ColumnNumber
Expected: 2
But was: 0
* Bump mono
* [builds] Install the old llvm binaries into the LLVM36 directory and make the 32 bit builds use that.
* Bump mono
* Bump mono
* [jenkins] Don't give VSTS a fake branch. (#4667)
Something in VSTS changed, and now fake branch names don't work anymore.
So instead use real branch names (and for pull requests I've created a
'pull-request' branch we can use).
* Assembly.LoadFile accepts only absolute path
* [linker] Add new Facade (System.Threading.Tasks.Extensions).
Fixes these MTouch test failures:
1. Xamarin.Linker.SdkTest.iOS_Unified : Facades
Expected:
But was: < "System.Threading.Tasks.Extensions" >
2. Xamarin.Linker.SdkTest.tvOS : Facades
Expected:
But was: < "System.Threading.Tasks.Extensions" >
3. Xamarin.Linker.SdkTest.watchOS : Facades
Expected:
But was: < "System.Threading.Tasks.Extensions" >
* [mono-sdks] Necessary changes to unify the LLVM provisioning for both iOS and Android. (#4732)
* Bump Mono
* [mtouch] add mixed-mode support (#4751)
* [mtouch] add --interp-mixed option
When enabling this option, mtouch will AOT compile `mscorlib.dll`. At
runtime that means every method that wasn't AOT'd will be executed by
the runtime interpreter.
* [mtouch] Add support to --interpreter to list the assemblies to (not) interpret.
* [msbuild] Simplify interpreter code to use a single variable.
* Fix whitespace.
* [mtouch] Move mtouch-specific code to mtouch-specific file.
* [msbuild] An empty string is a valid value for 'Interpreter', so make it a non-required property.
* [mtouch] Add sanity check for aot-compiling interpreted assemblies.
* Bump Mono
* [linker] Updates SDKs facades list
* Bump mono
* [msbuild] Adds facades which might override default nuget version to framework list
The collision resolver task reads them from here https://github.com/dotnet/sdk/blob/master/src/Tasks/Common/ConflictResolution/FrameworkListReader.cs
* Bump to a VSfM version that can build XM Classic projects.
* Add support for delegates as return values in protocol members. Fixes#4102.
This required a few changes:
* The generator now emits the DelegateProxy attribute for property getters in
protocol interfaces.
* The generator now emits the DelegateProxy attribute in ProtocolMember
attributes (and the ProtocolMember attribute has been extended with
additional properties for this purpose).
* The generator now emits the BlockProxy attribute for the parameter in
property setters.
* The generator now emits the BlockProxy attribute in ProtocolMember
attributes for property setters.
* The static registrar now emits the metadata token for the
DelegateProxy.DelegateType property into the generated code so that the
DelegateProxy attribute itself isn't needed at runtime. This is required
when the dynamic registrar has been optimized away.
Fixes https://github.com/xamarin/xamarin-macios/issues/4102.
* [tests] Update MX4105 test to expect new warnings.
* Store the minimum mono version for Xamarin.Mac in one place only (Make.config) and bump it to 5.14. Fixes#4120.
I've verified that we fail at launch of running on 5.12, while 5.14 works fine
(to launch at least), so the minimum system mono version is _at least_ 5.14.
Fixes https://github.com/xamarin/xamarin-macios/issues/4120.
* [mmp] Load mono's version file instead of using pkg-config to get mono's version.
pkg-config will only get three parts of the version, while the version file
has all four parts.
This is important, since we're now verifying the four parts of the version
file, and without loading those four from the system, we'll fail builds like
this:
error MM0001: This version of Xamarin.Mac requires Mono 5.14.0.136 (the current Mono version is 5.14.0).
because the three part version's fourth number is assumed to be 0.
* Only verify mono runtime version when running with system/dynamic mono.
There should be no need to verify the mono runtime version when embedding mono:
* If it's a mono we're shipping, something very bad happened in our
build/package for it to be an invalid mono.
* If it's a system mono that's being embedded, then we verify in mmp at build
time.
In the first scenario (a mono we're shipping), the problem is that the mono
we've built does not report back the full version number (with four parts) [1],
which means we'll fail any check whose requirements are identical for the
first three parts, and non-zero for the last.
[1] The fourth part of the version number is created/calculated when packaging
mono, and we're not packaging it.
* [src] Fix bgen build to support custom output directory for api comparison. Fixes maccore#959.
This broke in 87c27e0c3f, which made bgen
compile using a project file (I forgot to verify that it wouldn't affect the
API comparison, and the PR build didn't complain because problems with the API
comparison typically show up in subsequent PRs).
https://github.com/xamarin/maccore/issues/959
* [src] Fix response file usage to use BUILD_DIR, so that API comparison can redirect as expected.
* [src] Fix generation of generator.csproj's dependency file to use BUILD_DIR, so that API comparison can redirect as expected.
* [src] Fix bgen.exe's dependencies.
* Use full paths to create-makefile-fragment.sh.
Linking with CoreNFC crash applications on iOS 12 on iPad (and likely
other device not supporting, or supported, for NFC).
This used to work on iOS 11.x (when introduced). The solution is to
always **weak** link CoreNFC (since we can't guess devices)
https://github.com/xamarin/xamarin-macios/issues/4628
* CoreFoundation/DispatchData: avoid possible integer overflow
* Network: move attributes for types introduced in Xcode10 from the
members to the types.
* Network: for callbacks that surface INativeObjects, rather than using
* Hide P/Invokes that are not currently surfaced so xtro tests can track this
* guidelines: Ip -> IP
* SecIdentity2: fix a leak by releasing the returned array, check for handle being null.
* SecTrust2: check for handle being null.
Fixes this problem in the MT4134 test:
Process exited with code 1, command:
/Applications/Xcode83.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -Wno-receiver-forward-class -Wno-objc-missing-super-calls -gdwarf-2 -I/Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/usr/include -isysroot /Applications/Xcode83.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator10.3.sdk -Qunused-arguments -fobjc-legacy-dispatch -fobjc-abi-version=2 -mios-simulator-version-min=11.4 -arch x86_64 -c -o /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory513/mtouch-test-cache/x86_64/registrar.o -x objective-c++ /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory513/mtouch-test-cache/registrar.m
In file included from /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory513/mtouch-test-cache/registrar.m:2:
/Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory513/mtouch-test-cache/registrar.h:47:9: fatal error: 'MetalPerformanceShaders/MetalPerformanceShaders.h' file not found
#import <MetalPerformanceShaders/MetalPerformanceShaders.h>
Note that the error is because the test is building with Xcode 8.3 (and this
is also why the problem wasn't found by the PR bots: they don't have older
Xcodes installed to run this particular test).
Unify the code to detect frameworks that aren't supported in the simulator (we
had switches in two places, now this data is stored per framework).
Also remove some of the Metal frameworks for some of the platforms from these
lists (since they're now available in the simulator in some cases), which
fixes#4422.
It also seems CoreAudioKit is now available in the simulator (it wasn't in the
first Xcode 7 beta, but apparently added in a later beta. This made our
exclusion incorrect, but we never noticed).
https://github.com/xamarin/xamarin-macios/issues/4422
* Convert it into a MM8027/MT8027 error (with documentation).
* Add information about the selector and managed method that triggered the error.
Now the problem reported in issue #4254 shows up as:
> ObjCRuntime.RuntimeException: Failed to marshal the Objective-C object 0x7f8080412810 (type: UIView). Could not find an existing managed instance for this object, nor was it possible to create a new managed instance (because the type 'UIKit.UIView&' does not have a constructor that takes one IntPtr argument).
> Additional information:
> Selector: popoverController:willRepositionPopoverToRect:inView:
> Method: UIKit.UIPopoverController+_UIPopoverControllerDelegate.WillReposition(UIKit.UIPopoverController, CoreGraphics.CGRect ByRef, UIKit.UIView ByRef)
instead of just:
> ObjCRuntime.RuntimeException: Failed to marshal the Objective-C object 0x7f8080412810 (type: UIView). Could not find an existing managed instance for this object, nor was it possible to create a new managed instance (because the type 'UIKit.UIView&' does not have a constructor that takes one IntPtr argument).
which makes it much easier to understand, track down, and fix/work around,
both for customers and ourselves.
* [tests] Add introspection tests to ensure there are native linking instructions for all frameworks. Fixes#3976
or a good, documented (in test code) reason for not needing it.
https://github.com/xamarin/xamarin-macios/issues/3976
* Fix failures
- static registrar failed on 32bits because one type in PhotoUI missed
its `onlyOn64: true`
- link with the top, not the sub-frameworks
* [tvos] Fix mistakes in tvOS where some extranous types triggered unrequired/unavailable (or missing) frameworks
* [watchos] Fix watchOS frameworks mapping
* Bump to use Xcode 10 beta 1
* Update Versions.plist
* Add a dependency on Xcode 9.4.
* [msbuild] Fix build with Xcode 10 beta 1. (#4182)
Many years ago (in Xcode 7 according to code comment)
Developer/Platforms/iPhoneOS.platform/Developer/usr disappeared, and we coped
by looking at Developer/usr instead (and also the subsequent code to locate
the bin directory was based on the location of the usr directory).
Developer/Platforms/iPhoneOS.platform/Developer/usr reappeared in Xcode 10
beta 1, but it seems useless (for one it doesn't contain a bin directory), so
in order to try to keep things sane don't look for this directory in Xcode 10
and instead go directly for Developer/usr (which is what we've been using as
the usr directory for years anyway).
Fixes this problem when building apps with Xcode 10 beta 1:
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets(626,3): error : Could not locate SDK bin directory [/Users/rolf/Projects/TestApp/test-app.csproj]
* [runtime] Build 32-bit mac executables using Xcode 9.4.
* [mtouch] Work around broken tvOS headers in Xcode 10 beta 1.
* [mtouch] Work around build problem with Apple's simd headers in Objective-C++ mode.
* Use version-agnostic paths to sdk directories.
* [tests][xtro] Add todo files (from unclassified) and adjust ignore files to avoid errors
* [macos][security] Re-enable SSL[Get|Set]AlpnProtocols. Fixes#4001 (#4022)
* [macos][security] Re-enable SSL[Get}Set]AlpnProtocols. Fixes#4001
This was fixed in macOS 10.13.4
https://github.com/xamarin/xamarin-macios/issues/4001
* [tests][monotouch-tests] Disable a few test cases (one crasher, other failures). Causes to be verified later
* [xharness] Fix permission dialog suppression in Xcode 10.
* [xharness] Ignore 32-bit macOS tests by default.
* [tests] Execute mmp regression tests with Xcode 9.4 since many of them are 32-bit and needs porting to 64-bit.
* [mmptest] Ignore 32-bit XM tests if we don't have a 32-bit-capable Xcode.
* [registrar] Add workaround for broken headers in Xcode 10 beta 1 (radar 40824697).
* [mtouch] Restrict another workaround for an Xcode 10 beta 1 bug to a specific Xcode version to remove it asap.
* [tests] Fix some protocol changes (public or not) find by introspection tests
* [tests][intro] Fix DefaultCtorAllowed failures
* [Intents] Obsolete several Intents classes in watchOS.
Several existing Intents classes have been marked as unavailable in watchOS in
the headers in Xcode 10 beta 1, and corresponding tests are now failing.
So obsolete the managed wrapper types, and fix tests accordingly.
* Fix xtro wrt previous Ietents/intro changes
* [tests] Minor adjustments to mtouch tests to work with Xcode 10.
* [msbuild] Update tests to cope with additional files produced by the Core ML compiler.
* [msbuild] Xcode 10 doesn't support building watchOS 1 apps, so show a clear error message explaining it.
Also update tests accordingly.
* [coreimage] Stub new filters and exclude ?removed? ones from tests
* Update GameplayKit and SpriteKit NSSecureCoding _upgrade_ and fix other non-public cases (in tests)
* [tests] Ignore some GameKit selectors that don't respond anymore (but seems to be available, at least in header files)
* [tests] Fix intro 32bits testing for filters resutls
* [msbuild] Slightly change error message to be better English.
* [tests] Add introspection tests to ensure there are native linking instructions for all frameworks. Fixes#3976
or a good, documented (in test code) reason for not needing it.
https://github.com/xamarin/xamarin-macios/issues/3976
* Fix failures
- static registrar failed on 32bits because one type in PhotoUI missed
its `onlyOn64: true`
- link with the top, not the sub-frameworks
* [tvos] Fix mistakes in tvOS where some extranous types triggered unrequired/unavailable (or missing) frameworks
* [watchos] Fix watchOS frameworks mapping
* [tests] Add introspection tests to ensure there are native linking instructions for all frameworks. Fixes#3976
or a good, documented (in test code) reason for not needing it.
https://github.com/xamarin/xamarin-macios/issues/3976
* Fix failures
- static registrar failed on 32bits because one type in PhotoUI missed
its `onlyOn64: true`
- link with the top, not the sub-frameworks
* [tvos] Fix mistakes in tvOS where some extranous types triggered unrequired/unavailable (or missing) frameworks
* [watchos] Fix watchOS frameworks mapping
* [Compression] Ensure we use the correct lonking flags for older versions. Fixes#4129.
Libcompresison was added after iOs 9.0, TvOS 9.0, Mac 10.11 and Watch
2.0. We want to use weak in those older platforms.
Fixes issue https://github.com/xamarin/xamarin-macios/issues/4129
Commit list for mono/mono:
* mono/mono@1c24c158b0 [bitcode] Fix the generation of invalid llvm IR for some Span code.
* mono/mono@a49a68c6d7 [interp] Fix native to interp transition (#8957)
* mono/mono@92e11812f4 [System.Runtime.Serialization] Makes more APIs work for mobile
* mono/mono@260676f948 Bump API snapshot submodule
* mono/mono@eefdf4ed31 Bump external/cecil to b6c50e3
* mono/mono@0754926394 [2018-02] Finalize merp integration (#8869)
Diff: 7bdb7dd765...1c24c158b0
* [mtouch][mmp] Have CoreResolver check for the new SymbolsNotMatchingException from Cecil
* [tests] Rebuild MX4175 in a separate .app to avoid debug symbol warnings
The newer cecil version is better at detecting incorrect .mdb, like the
test is using, resulting in warnings since the 2nd build (same location)
was done without symbols (so old ones were loaded).
Stale debug symbols is not the goal of the MX4175 test. Rebuilding the
.app in another directory solves the extra warning issue.
Commit list for mono/mono:
* mono/mono@1c24c158b0 [bitcode] Fix the generation of invalid llvm IR for some Span code.
* mono/mono@a49a68c6d7 [interp] Fix native to interp transition (#8957)
* mono/mono@92e11812f4 [System.Runtime.Serialization] Makes more APIs work for mobile
* mono/mono@260676f948 Bump API snapshot submodule
* mono/mono@eefdf4ed31 Bump external/cecil to b6c50e3
* mono/mono@0754926394 [2018-02] Finalize merp integration (#8869)
Diff: 7bdb7dd765...1c24c158b0
* [mtouch][mmp] Have CoreResolver check for the new SymbolsNotMatchingException from Cecil
* [tests] Rebuild MX4175 in a separate .app to avoid debug symbol warnings
The newer cecil version is better at detecting incorrect .mdb, like the
test is using, resulting in warnings since the 2nd build (same location)
was done without symbols (so old ones were loaded).
Stale debug symbols is not the goal of the MX4175 test. Rebuilding the
.app in another directory solves the extra warning issue.
In my test project 969828 instances (67MB) of `ReaderParameters` were
created by `CoreResolver.Resolve`, which always allocated a new one.
Since we already create them, most of the time*, we can reuse the
instances when additional members requires resolving.
* only 14 additional instances are now required
* Share the stopwatch code between `mtouch` and `mmp`;
* Add more details on linker steps. Sadly substeps are executed on the
metadata so they can't be reported individually;
* Add a few places where timestamps where missing to get better precision
on the linking part;
* [mtouch/mmp] Handle invalid types in BlockProxy attributes better. Fixes#4072.
BlockProxy attributes may have types we don't expect, so handle those cases
gracefully by showing a warning when we encounter them:
testApp.cs(11): warning MT4175: The parameter 'completionHandler' in the method 'Issue4072Session.CreateDataTask(Foundation.NSUrl,Foundation.NSUrlSessionResponse)' has an invalid BlockProxy attribute (the type passed to the attribute does not have a 'Create' method).
instead of an ugly MT0000:
MTOUCH : error MT0000: Unexpected error - Please file a bug report at http://bugzilla.xamarin.com
System.InvalidOperationException: Sequence contains no matching element
at System.Linq.Enumerable.First[TSource] (System.Collections.Generic.IEnumerable`1[T] source, System.Func`2[T,TResult] predicate) [0x00012] in /Users/builder/jenkins/workspace/build-package-osx-mono/2017-12/external/bockbuild/builds/mono-x64/external/corefx/src/System.Linq/src/System/Linq/First.cs:30
at Registrar.StaticRegistrar.GetBlockProxyAttributeMethod (Mono.Cecil.MethodDefinition method, System.Int32 parameter) [0x00020] in /Users/builder/data/lanes/5944/7e782c1e/source/xamarin-macios/tools/common/StaticRegistrar.cs:4121
at Registrar.StaticRegistrar.GetBlockWrapperCreator (Registrar.Registrar+ObjCMethod obj_method, System.Int32 parameter) [0x00011] in /Users/builder/data/lanes/5944/7e782c1e/source/xamarin-macios/tools/common/StaticRegistrar.cs:4065
at Registrar.StaticRegistrar.Specialize (Registrar.AutoIndentStringBuilder sb, Registrar.Registrar+ObjCMethod method, System.Collections.Generic.List`1[T] exceptions) [0x0216b] in /Users/builder/data/lanes/5944/7e782c1e/source/xamarin-macios/tools/common/StaticRegistrar.cs:3683
at Registrar.StaticRegistrar.Specialize (Registrar.AutoIndentStringBuilder sb) [0x00f1e] in /Users/builder/data/lanes/5944/7e782c1e/source/xamarin-macios/tools/common/StaticRegistrar.cs:2963
Fixes#4072.
* [docs] Improve text for MT4175.
* [registrar] Comment some code.
* [runtime] build interp-, icalltable- and ilgen libraries so they can be consumed in interpreter configuration
* [mtouch] add --interpreter configuration support
* [xharness] Add support for removing defines from cloned project files.
* [xharness] Run monotouch-test, mscorlib and mini tests with the interpreter too.
They're ignored for now, which means we won't run them on the bots.
* [mtouch] We're using dlsym when using the interpreter.
* [xharness] enable mini regression tests with interpreter on CI
The PR is not final and cannot be merged until the final Xcode 9.4
release from Apple is available.
Since there's no macOS specific changes (at least up to beta 2) we can
directly merge into the _normal_ milestone branch and avoid having
separate branches to maintain for XI and XM (until 15.8).
watchOS extensions are top-level containers in our build (because we ignore
watchOS apps entirely in mtouch), so treat them as such when computing the
protocol member map.
Fixes issue https://github.com/xamarin/xamarin-macios/issues/3930.
Fix parsing of --root-assembly to make the assembly required. This also means
that `--root-assembly /path/to/assembly` (a space separator instead of colon
or equals) will now work.
watchOS extensions are top-level containers in our build (because we ignore
watchOS apps entirely in mtouch), so treat them as such when computing the
protocol member map.
Fixes issue https://github.com/xamarin/xamarin-macios/issues/3930.
* Move Registrar.SanitizeName to StringUtils.SanitizeObjectiveCName.
* [generator] Register models with unique names to not match platform types. Fixes#3875.
* [NSObject] Don't compare against a non-existent protocol.
* [generator] Make it possible to register models like before if the binding developer wishes it.
* [src] Make sure to not declare ObjC classes Apple already defines.
Fixes these warnings at startup:
Class DOMNodeFilter is implemented in both /System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebKitLegacy.framework/Versions/A/WebKitLegacy (0x7fffa944a788) and /Users/builder/data/lanes/6035/0ca02336/source/xamarin-macios/tests/xharness/tmp-test-dir/dont link-mac-unified/bin/x86/Debug-unified/dont link.app/Contents/MacOS/dont link (0x10d8a9958). One of the two will be used. Which one is undefined.
Class WebOpenPanelResultListener is implemented in both /System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebKitLegacy.framework/Versions/A/WebKitLegacy (0x7fffa944e4c8) and /Users/builder/data/lanes/6035/0ca02336/source/xamarin-macios/tests/xharness/tmp-test-dir/dont link-mac-unified/bin/x86/Debug-unified/dont link.app/Contents/MacOS/dont link (0x10d8a9a98). One of the two will be used. Which one is undefined.
Class WebPolicyDecisionListener is implemented in both /System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebKitLegacy.framework/Versions/A/WebKitLegacy (0x7fffa944e838) and /Users/builder/data/lanes/6035/0ca02336/source/xamarin-macios/tests/xharness/tmp-test-dir/dont link-mac-unified/bin/x86/Debug-unified/dont link.app/Contents/MacOS/dont link (0x10d8a9ae8). One of the two will be used. Which one is undefined.
Class MTLCaptureScope is implemented in both /System/Library/Frameworks/Metal.framework/Versions/A/Metal (0x7fffa806f1d0) and /Users/builder/data/lanes/6035/0ca02336/source/xamarin-macios/tests/xharness/tmp-test-dir/dont link-mac-unified/bin/x86/Debug-unified/dont link.app/Contents/MacOS/dont link (0x10d8aa858). One of the two will be used. Which one is undefined.
Class JSExport is implemented in both /System/Library/Frameworks/JavaScriptCore.framework/Versions/A/JavaScriptCore (0x7fffa7eb4f60) and /Users/builder/data/lanes/6035/0ca02336/source/xamarin-macios/tests/xharness/tmp-test-dir/dont link-mac-unified/bin/x86/Debug-unified/dont link.app/Contents/MacOS/dont link (0x10d8aaa38). One of the two will be used. Which one is undefined.
* Move Registrar.SanitizeName to StringUtils.SanitizeObjectiveCName.
* [generator] Register models with unique names to not match platform types. Fixes#3875.
* [NSObject] Don't compare against a non-existent protocol.
* [generator] Make it possible to register models like before if the binding developer wishes it.
* [src] Make sure to not declare ObjC classes Apple already defines.
Fixes these warnings at startup:
Class DOMNodeFilter is implemented in both /System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebKitLegacy.framework/Versions/A/WebKitLegacy (0x7fffa944a788) and /Users/builder/data/lanes/6035/0ca02336/source/xamarin-macios/tests/xharness/tmp-test-dir/dont link-mac-unified/bin/x86/Debug-unified/dont link.app/Contents/MacOS/dont link (0x10d8a9958). One of the two will be used. Which one is undefined.
Class WebOpenPanelResultListener is implemented in both /System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebKitLegacy.framework/Versions/A/WebKitLegacy (0x7fffa944e4c8) and /Users/builder/data/lanes/6035/0ca02336/source/xamarin-macios/tests/xharness/tmp-test-dir/dont link-mac-unified/bin/x86/Debug-unified/dont link.app/Contents/MacOS/dont link (0x10d8a9a98). One of the two will be used. Which one is undefined.
Class WebPolicyDecisionListener is implemented in both /System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebKitLegacy.framework/Versions/A/WebKitLegacy (0x7fffa944e838) and /Users/builder/data/lanes/6035/0ca02336/source/xamarin-macios/tests/xharness/tmp-test-dir/dont link-mac-unified/bin/x86/Debug-unified/dont link.app/Contents/MacOS/dont link (0x10d8a9ae8). One of the two will be used. Which one is undefined.
Class MTLCaptureScope is implemented in both /System/Library/Frameworks/Metal.framework/Versions/A/Metal (0x7fffa806f1d0) and /Users/builder/data/lanes/6035/0ca02336/source/xamarin-macios/tests/xharness/tmp-test-dir/dont link-mac-unified/bin/x86/Debug-unified/dont link.app/Contents/MacOS/dont link (0x10d8aa858). One of the two will be used. Which one is undefined.
Class JSExport is implemented in both /System/Library/Frameworks/JavaScriptCore.framework/Versions/A/JavaScriptCore (0x7fffa7eb4f60) and /Users/builder/data/lanes/6035/0ca02336/source/xamarin-macios/tests/xharness/tmp-test-dir/dont link-mac-unified/bin/x86/Debug-unified/dont link.app/Contents/MacOS/dont link (0x10d8aaa38). One of the two will be used. Which one is undefined.
* [ClassKit] Add Xcode 9.4 Beta 1 Bindings
* ClassKit moved to v11.4 or we'd link against a private frmework in 11.3
* Turn CLSPredicateKeyPath into a static class
CLSPredicateKeyPath does not make much sense as an enum, we'll use
a static class instead so we do not have to call GetConstant() and
use the NSString directly.
Sample code using CLSPredicateKeyPath:
```csharp
var store = CLSDataStore.Shared;
var predicate = NSPredicate.FromFormat ("%K = %@", CLSPredicateKeyPath.Parent, store.MainAppContext);
var ctxs = await store.FindContextsMatchingAsync (predicate);
foreach (var ctx in ctxs) {
Console.WriteLine (ctx.Title);
}
```
* [tests] Exclude WeakTopic incorrect check, bound as smart enum
- https://github.com/xamarin/xamarin-macios/issues/3725
- These frameworks "CoreAudioKit Metal MetalKit MetalPerformanceShaders CoreNFC DeviceCheck"
were special cased, but that special case did do an SDK check.
- Create a helper method to share check
- Add test for MM0135
- https://github.com/xamarin/xamarin-macios/issues/3725
- These frameworks "CoreAudioKit Metal MetalKit MetalPerformanceShaders CoreNFC DeviceCheck"
were special cased, but that special case did do an SDK check.
- Create a helper method to share check
- Add test for MM0135
Add support for blocks in static protocol members by adding another field to
the [ProtocolMember] attribute that specifies the block proxy type.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=41226.
If a class implements a protocol with optional members, and that class also exports methods whose selectors match an optional member, but the signature doesn't match, we must show a useful warning instead of erroring out due to a NullReferenceException.
Fixes this:
System.NullReferenceException: Object reference not set to an instance of an object
at Registrar.StaticRegistrar.GetBlockProxyAttributeMethod (Mono.Cecil.MethodDefinition method, System.Int32 parameter) [0x00001] in /Users/builder/data/lanes/1381/9de35b83/source/xamarin-macios/tools/common/StaticRegistrar.cs:4113
at Registrar.StaticRegistrar.GetBlockWrapperCreator (Registrar.Registrar+ObjCMethod obj_method, System.Int32 parameter) [0x001e1] in /Users/builder/data/lanes/1381/9de35b83/source/xamarin-macios/tools/common/StaticRegistrar.cs:4101
at Registrar.StaticRegistrar.Specialize (Registrar.AutoIndentStringBuilder sb, Registrar.Registrar+ObjCMethod method, System.Collections.Generic.List`1[T] exceptions) [0x0216b] in /Users/builder/data/lanes/1381/9de35b83/source/xamarin-macios/tools/common/StaticRegistrar.cs:3683
when building the msbuild/tests/MyWatchKit2IntentsExtension project.
* [MMP] Revert recursive search dirs changes
* [MMP] Allow resolving assemblies to the ones passed in command line args
This is what actually makes the MonoMacResolver actually resolve to
assemblies given as arguments.
This mirrors the behaviour of Pack, which is called on the other
code-path (that's not --runregistrar)
3113c5d2b5/tools/mmp/driver.cs (L513)
If a class implements a protocol with optional members, and that class also exports methods whose selectors match an optional member, but the signature doesn't match, we must show a useful warning instead of erroring out due to a NullReferenceException.
Fixes this:
System.NullReferenceException: Object reference not set to an instance of an object
at Registrar.StaticRegistrar.GetBlockProxyAttributeMethod (Mono.Cecil.MethodDefinition method, System.Int32 parameter) [0x00001] in /Users/builder/data/lanes/1381/9de35b83/source/xamarin-macios/tools/common/StaticRegistrar.cs:4113
at Registrar.StaticRegistrar.GetBlockWrapperCreator (Registrar.Registrar+ObjCMethod obj_method, System.Int32 parameter) [0x001e1] in /Users/builder/data/lanes/1381/9de35b83/source/xamarin-macios/tools/common/StaticRegistrar.cs:4101
at Registrar.StaticRegistrar.Specialize (Registrar.AutoIndentStringBuilder sb, Registrar.Registrar+ObjCMethod method, System.Collections.Generic.List`1[T] exceptions) [0x0216b] in /Users/builder/data/lanes/1381/9de35b83/source/xamarin-macios/tools/common/StaticRegistrar.cs:3683
when building the msbuild/tests/MyWatchKit2IntentsExtension project.
* [static registrar] Optimize creation of delegates for blocks.
Optimize creation of delegates for blocks so that it doesn't require the
dynamic registrar.
This is done by getting the metadata token for the Create method that creates
the delegate, and embed that metadata token in the generated code from the
static registrar.
Also add tests, since this scenario was not covered by tests already.
* [mmptest] Fix test after recent changes.
* [test-libraries] Avoid duplicate symbols.
* [tests] Update according to changes.
At some point the code wasn't able to figure out the framework for linked away
types (because linked away types don't know which assembly they belong to, and
thus we couldn't verify that the type in question was a platform type or not),
so I skipped checking the namespace for such types.
Some time later I implemented support for storing the assembly for a linked
away type separately, so that it can later be looked up, and thus it's not
necessary to exclude linked away types anymore.
This fixes a build problem with the generated registrar code (which happens
only if the INCWidgetProviding interface is linked away) when building the
linkall extension tests:
/work/maccore/master/xamarin-macios/tests/xharness/tmp-test-dir/link all1894/obj/iPhone/Debug64-today-extension/mtouch-cache/registrar.h:319:51: error: no type or protocol named 'NCWidgetProviding'
@interface TodayViewController : UIViewController<NCWidgetProviding> {
^
* [MMP] Revert recursive search dirs changes
* [MMP] Allow resolving assemblies to the ones passed in command line args
This is what actually makes the MonoMacResolver actually resolve to
assemblies given as arguments.
This mirrors the behaviour of Pack, which is called on the other
code-path (that's not --runregistrar)
3113c5d2b5/tools/mmp/driver.cs (L513)
- https://github.com/xamarin/xamarin-macios/issues/3367
- App Store will now fail builds if you add in a 32-bit dylib
- If you are a 32-bit app you don't need the 64-bit part of your fat
dylib anyway
- Add --optimize=-trim-architectures to allow customization of behavior, as not everyone
uses app store
In addition, while writing tests for this is was noticed that mmp tests did not "really" run Release configuration correctly in most cases. Fixing this turned out to be a bit of a pain, but necessary to correctly test this (and other things).
- Turns out that /p:configuration:debug is not sufficient to tell mmp to
do the right thing
- That, in most projects, sets the DebugSymbols property, which really
is what is checked.
- However, two of our projects did not have that, so we always did
release mmp work.
- Removed configuration property for tests and added real "Release"
configuration option
* [static registrar] Optimize creation of delegates for blocks.
Optimize creation of delegates for blocks so that it doesn't require the
dynamic registrar.
This is done by getting the metadata token for the Create method that creates
the delegate, and embed that metadata token in the generated code from the
static registrar.
Also add tests, since this scenario was not covered by tests already.
* [mmptest] Fix test after recent changes.
* [test-libraries] Avoid duplicate symbols.
* [tests] Update according to changes.
- https://github.com/xamarin/xamarin-macios/issues/3367
- App Store will now fail builds if you add in a 32-bit dylib
- If you are a 32-bit app you don't need the 64-bit part of your fat
dylib anyway
- Add --optimize=-trim-architectures to allow customization of behavior, as not everyone
uses app store
In addition, while writing tests for this is was noticed that mmp tests did not "really" run Release configuration correctly in most cases. Fixing this turned out to be a bit of a pain, but necessary to correctly test this (and other things).
- Turns out that /p:configuration:debug is not sufficient to tell mmp to
do the right thing
- That, in most projects, sets the DebugSymbols property, which really
is what is checked.
- However, two of our projects did not have that, so we always did
release mmp work.
- Removed configuration property for tests and added real "Release"
configuration option
At some point the code wasn't able to figure out the framework for linked away
types (because linked away types don't know which assembly they belong to, and
thus we couldn't verify that the type in question was a platform type or not),
so I skipped checking the namespace for such types.
Some time later I implemented support for storing the assembly for a linked
away type separately, so that it can later be looked up, and thus it's not
necessary to exclude linked away types anymore.
This fixes a build problem with the generated registrar code (which happens
only if the INCWidgetProviding interface is linked away) when building the
linkall extension tests:
/work/maccore/master/xamarin-macios/tests/xharness/tmp-test-dir/link all1894/obj/iPhone/Debug64-today-extension/mtouch-cache/registrar.h:319:51: error: no type or protocol named 'NCWidgetProviding'
@interface TodayViewController : UIViewController<NCWidgetProviding> {
^
* [registrar] Fix resolving linked away generic types. Fixes#3523.
Fixes#3523.
* [tests] Use a link all test instead of mtouch test.
It's much faster, since we're already building link all everywhere.
* [tests] Use the static registrar in all linkall simulator configurations.
When code sharing is enabled, only the container app/target will have a
LinkContext.
So make sure the static registrar finds that link context when it needs
information from the linker.
https://github.com/xamarin/xamarin-macios/issues/3514
* [registrar] Fix resolving linked away generic types. Fixes#3523.
Fixes#3523.
* [tests] Use a link all test instead of mtouch test.
It's much faster, since we're already building link all everywhere.
* [tests] Use the static registrar in all linkall simulator configurations.
When code sharing is enabled, only the container app/target will have a
LinkContext.
So make sure the static registrar finds that link context when it needs
information from the linker.
https://github.com/xamarin/xamarin-macios/issues/3514
* [tests] Improve debug spew for the RebuildTest_WithExtensions test.
* [mtouch/mmp] Store/load if the dynamic registrar is removed or not into the cached link results.
Store/load if the dynamic registrar is removed or not into the cached link
results, so that we generate the correct main.m even if cached linker results
are used.
* [mtouch/mmp] The static registrar must not execute if we're loading cached results from the linker.
The static registrar must not execute if we're loading cached results from the
linker, because the static registrar needs information from the linker that's
not restored from the cache.
* [mtouch/mmp] Share Touch code.
* [mtouch/mmp] Make it possible to touch inexistent files (to create them).
* [mtouch/mmp] Fix tracking of whether the static registrar should run again or not.
The recent changes to support optimizing away the dynamic registrar caused the
Xamarin.MTouch.RebuildTest_WithExtensions test to regress.
The problem
-----------
* The linker now collects and stores information the static registrar needs.
* This information is not restored from disk when the linker realizes that it
can reload previously linked assemblies instead of executing again.
* The static registrar runs again (for another reason).
* The information the static registrar needs isn't available, and incorrect
output follows.
So fix 1: show an error if the static registrar runs when the linker loaded
cached results.
The exact scenario the test ran into is this:
* 1st build: everything is new and everything is built.
* 2nd build: contents of .exe changes, the linker runs again, the static
registrar runs again, but sees that the generated output didn't change, so
it doesn't write the new content to disk (this is an optimization to avoid
compiling the registrar.m file again unless needed).
* 3rd build: only the .exe timestamp changes, the linker sees nothing changes
in the contents of the .exe and loads the previously linked assemblies from
disk, the static registrar sees that the .exe's timestamp is newer than
registrar.m's timestamp and run again, but doesn't produce the right result
because it doesn't have the information it needs.
Considered solutions
--------------------
1. Only track timestamps, not file contents. This is not ideal, since it will
result in more work done: in particular for the case above, it would add a
registrar.m compilation in build #2, and linker rerun + static registrar
rerun + registrar.m compilation + final native link in build #3.
2. Always write the output of the static registrar, even if it hasn't changed.
This is not ideal either, since it will also result in more work done: for
the case above, it would add a registrar.m compilation + final native link
in build #3.
3. Always write the output of the static registrar, but track if it changed or
not, and if it didn't, just touch registrar.o instead of recompiling it.
This only means the final native link in build #3 is added (see #5 for why
this is worse than it sounds).
4. Always write the output of the static registrar, but track it it changed or
not, and if it didn't, just touch registrar.o instead of recompiling it,
and track that too, so that the final native link in build #3 isn't needed
anymore. Unfortunately this may result in incorrect behavior, because now
the msbuild tasks will detect that the executable has changed, and may run
dsymutil + strip again. The executable didn't actually change, which means
it would be the previously stripped executable, and thus we'd end up with
an empty .dSYM because we ran dsymtil on an already stripped executable.
5. Idea #4, but write the output of the final link into a temporary directory
instead of the .app, so that we could track whether we should update the
executable in the .app or not. This is not optimal either, because
executables can be *big* (I've seen multi-GB tvOS bitcode executables), and
extra copies of such files should not be taken lightly.
6. Idea #4, but tell the MSBuild tasks that dsymutil/strip doesn't need to be
rerun even if the timestamp of the executable changed. This might actually
work, but now the solution's become quite complex.
Implemented solution
--------------------
Use stamp files to detect whether a file is up-to-date or not.
In particular:
* When we don't write to a file because the new contents are identical to the
old contents, we now touch a .stamp file. This stamp file means "the
accompanying file was determined to be up-to-date when the stamp was
touched."
* When checking whether a file is up-to-date, also check for the presence of a
.stamp file, and if it exists, use the highest timestamp between the stamp
file and the actual file.
Now the test scenario becomes:
* 1st build: everything is new and everything is built.
* 2nd build: contents of .exe changes, the linker runs again, the static
registrar runs again, but sees that the generated output didn't change, so
it doesn't write the new content to disk, but it creates a registrar.m.stamp
file to indicate the point in time when registrar.m was considered up-to-
date.
* 3rd build: only the .exe timestamp changes, the linker sees nothing changes
in the contents of the .exe and loads the previously linked assemblies from
disk, the static registrar sees that the .exe's timestamp is *older* than
registrar.m.stamp's timestamp and doesn't run again.
We only use the stamp file for source code (registrar.[m|h], main.[m|h],
pinvokes.[m|h]), since using it every time has too much potential for running
into other problems (for instance we should never create .stamp files inside
the .app).
Fixes these test failures:
1) Failed : Xamarin.MTouch.RebuildTest_WithExtensions("single","",False,System.String[])
single
Expected: <empty>
But was: < "/Users/builder/data/lanes/5746/4123bf7e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory371/testApp.app/testApp is modified, timestamp: 2/15/2018 3:04:11 PM > 2/15/2018 3:04:09 PM" >
2) Failed : Xamarin.MTouch.RebuildTest_WithExtensions("dual","armv7,arm64",False,System.String[])
dual
Expected: <empty>
But was: < "/Users/builder/data/lanes/5746/4123bf7e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory375/testApp.app/testApp is modified, timestamp: 2/15/2018 3:06:03 PM > 2/15/2018 3:06:00 PM" >
3) Failed : Xamarin.MTouch.RebuildTest_WithExtensions("llvm","armv7+llvm",False,System.String[])
llvm
Expected: <empty>
But was: < "/Users/builder/data/lanes/5746/4123bf7e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory379/testApp.app/testApp is modified, timestamp: 2/15/2018 3:07:14 PM > 2/15/2018 3:07:12 PM" >
4) Failed : Xamarin.MTouch.RebuildTest_WithExtensions("debug","",True,System.String[])
debug
Expected: <empty>
But was: < "/Users/builder/data/lanes/5746/4123bf7e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory383/testApp.app/testApp is modified, timestamp: 2/15/2018 3:08:16 PM > 2/15/2018 3:08:13 PM" >
5) Failed : Xamarin.MTouch.RebuildTest_WithExtensions("single-framework","",False,System.String[])
single-framework
Expected: <empty>
But was: < "/Users/builder/data/lanes/5746/4123bf7e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory387/testApp.app/testApp is modified, timestamp: 2/15/2018 3:09:18 PM > 2/15/2018 3:09:16 PM" >
Fixes https://github.com/xamarin/maccore/issues/641
* [tests] Improve debug spew for the RebuildTest_WithExtensions test.
* [mtouch/mmp] Store/load if the dynamic registrar is removed or not into the cached link results.
Store/load if the dynamic registrar is removed or not into the cached link
results, so that we generate the correct main.m even if cached linker results
are used.
* [mtouch/mmp] The static registrar must not execute if we're loading cached results from the linker.
The static registrar must not execute if we're loading cached results from the
linker, because the static registrar needs information from the linker that's
not restored from the cache.
* [mtouch/mmp] Share Touch code.
* [mtouch/mmp] Make it possible to touch inexistent files (to create them).
* [mtouch/mmp] Fix tracking of whether the static registrar should run again or not.
The recent changes to support optimizing away the dynamic registrar caused the
Xamarin.MTouch.RebuildTest_WithExtensions test to regress.
The problem
-----------
* The linker now collects and stores information the static registrar needs.
* This information is not restored from disk when the linker realizes that it
can reload previously linked assemblies instead of executing again.
* The static registrar runs again (for another reason).
* The information the static registrar needs isn't available, and incorrect
output follows.
So fix 1: show an error if the static registrar runs when the linker loaded
cached results.
The exact scenario the test ran into is this:
* 1st build: everything is new and everything is built.
* 2nd build: contents of .exe changes, the linker runs again, the static
registrar runs again, but sees that the generated output didn't change, so
it doesn't write the new content to disk (this is an optimization to avoid
compiling the registrar.m file again unless needed).
* 3rd build: only the .exe timestamp changes, the linker sees nothing changes
in the contents of the .exe and loads the previously linked assemblies from
disk, the static registrar sees that the .exe's timestamp is newer than
registrar.m's timestamp and run again, but doesn't produce the right result
because it doesn't have the information it needs.
Considered solutions
--------------------
1. Only track timestamps, not file contents. This is not ideal, since it will
result in more work done: in particular for the case above, it would add a
registrar.m compilation in build #2, and linker rerun + static registrar
rerun + registrar.m compilation + final native link in build #3.
2. Always write the output of the static registrar, even if it hasn't changed.
This is not ideal either, since it will also result in more work done: for
the case above, it would add a registrar.m compilation + final native link
in build #3.
3. Always write the output of the static registrar, but track if it changed or
not, and if it didn't, just touch registrar.o instead of recompiling it.
This only means the final native link in build #3 is added (see #5 for why
this is worse than it sounds).
4. Always write the output of the static registrar, but track it it changed or
not, and if it didn't, just touch registrar.o instead of recompiling it,
and track that too, so that the final native link in build #3 isn't needed
anymore. Unfortunately this may result in incorrect behavior, because now
the msbuild tasks will detect that the executable has changed, and may run
dsymutil + strip again. The executable didn't actually change, which means
it would be the previously stripped executable, and thus we'd end up with
an empty .dSYM because we ran dsymtil on an already stripped executable.
5. Idea #4, but write the output of the final link into a temporary directory
instead of the .app, so that we could track whether we should update the
executable in the .app or not. This is not optimal either, because
executables can be *big* (I've seen multi-GB tvOS bitcode executables), and
extra copies of such files should not be taken lightly.
6. Idea #4, but tell the MSBuild tasks that dsymutil/strip doesn't need to be
rerun even if the timestamp of the executable changed. This might actually
work, but now the solution's become quite complex.
Implemented solution
--------------------
Use stamp files to detect whether a file is up-to-date or not.
In particular:
* When we don't write to a file because the new contents are identical to the
old contents, we now touch a .stamp file. This stamp file means "the
accompanying file was determined to be up-to-date when the stamp was
touched."
* When checking whether a file is up-to-date, also check for the presence of a
.stamp file, and if it exists, use the highest timestamp between the stamp
file and the actual file.
Now the test scenario becomes:
* 1st build: everything is new and everything is built.
* 2nd build: contents of .exe changes, the linker runs again, the static
registrar runs again, but sees that the generated output didn't change, so
it doesn't write the new content to disk, but it creates a registrar.m.stamp
file to indicate the point in time when registrar.m was considered up-to-
date.
* 3rd build: only the .exe timestamp changes, the linker sees nothing changes
in the contents of the .exe and loads the previously linked assemblies from
disk, the static registrar sees that the .exe's timestamp is *older* than
registrar.m.stamp's timestamp and doesn't run again.
We only use the stamp file for source code (registrar.[m|h], main.[m|h],
pinvokes.[m|h]), since using it every time has too much potential for running
into other problems (for instance we should never create .stamp files inside
the .app).
Fixes these test failures:
1) Failed : Xamarin.MTouch.RebuildTest_WithExtensions("single","",False,System.String[])
single
Expected: <empty>
But was: < "/Users/builder/data/lanes/5746/4123bf7e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory371/testApp.app/testApp is modified, timestamp: 2/15/2018 3:04:11 PM > 2/15/2018 3:04:09 PM" >
2) Failed : Xamarin.MTouch.RebuildTest_WithExtensions("dual","armv7,arm64",False,System.String[])
dual
Expected: <empty>
But was: < "/Users/builder/data/lanes/5746/4123bf7e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory375/testApp.app/testApp is modified, timestamp: 2/15/2018 3:06:03 PM > 2/15/2018 3:06:00 PM" >
3) Failed : Xamarin.MTouch.RebuildTest_WithExtensions("llvm","armv7+llvm",False,System.String[])
llvm
Expected: <empty>
But was: < "/Users/builder/data/lanes/5746/4123bf7e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory379/testApp.app/testApp is modified, timestamp: 2/15/2018 3:07:14 PM > 2/15/2018 3:07:12 PM" >
4) Failed : Xamarin.MTouch.RebuildTest_WithExtensions("debug","",True,System.String[])
debug
Expected: <empty>
But was: < "/Users/builder/data/lanes/5746/4123bf7e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory383/testApp.app/testApp is modified, timestamp: 2/15/2018 3:08:16 PM > 2/15/2018 3:08:13 PM" >
5) Failed : Xamarin.MTouch.RebuildTest_WithExtensions("single-framework","",False,System.String[])
single-framework
Expected: <empty>
But was: < "/Users/builder/data/lanes/5746/4123bf7e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory387/testApp.app/testApp is modified, timestamp: 2/15/2018 3:09:18 PM > 2/15/2018 3:09:16 PM" >
Fixes https://github.com/xamarin/maccore/issues/641
Create a table of interface -> protocol in the static registrar, since we need
to be able to look up a protocol given a managed type without looking at the
(possibly linked away) [Protocol] attribute.
* [tests] Fix relative paths in mmptest and make cloned XM nunit projects work properly.
Fixes this build problem with mmptest:
/Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/mmptest/CustomBuildActions.targets: error : Command 'make bin/SimpleClassDylib.dylib bin/SimpleClassStatic.a bin/Mobile-static/MobileBinding.dll' exited with code: 255.
Fixes https://github.com/xamarin/maccore/issues/633.
* [mmp] Improve Driver.IsDefaultMarshalingManagedExceptionMode to work before MarshalManagedException has been initialized.
Fixes this test failure:
1) Failed : Xamarin.MMP.Tests.MMPTests.UnifiedDebugBuilds_ShouldLinkToPartialStatic_UnlessDisabled
Debug build should use partial static registrar
Expected: True
But was: False
This regressed in 0561618460, where we wouldn't
properly select the partial static registrar because the initialization order
changed and we'd do it before selecting the default exception marshaling mode.
Changing Driver.IsDefaultMarshalingManagedExceptionMode to work before
MarshalManagedException has been initialized to its default value fixes the
problem.
Improved linker to:
* Not mark protocol interfaces by the mere virtue of having a type that
implements them. This is implemented by not marking protocol interfaces when
they're implementing a class, but instead when a method implementation is
found to implement a method from a protocol interface.
* Mark the wrapper type for protocols (this allows us to remove the Protocol
attribute, since that's the link between the protocol and its wrapper type).
* Remove the [Protocol], [ProtocolMember] and [Adopts] attributes.
The static registrar still needs some of the information linked away, so a few
changes are required to make it available post linker.
Generate table of protocols and their corresponding wrapper type in the static
registrar, so that we don't have to look for this information using the
dynamic registrar at runtime.
Fix warning about ignored optimizations to include 'register-protocols', since
it has conditions not in other optimizations (both the static registrar and
the linker must be enabled).
Make the generated static registrar code implement protocols from [Adopts]
attributes, so that we can just query the ObjC runtime to see if a type
implements a protocol instead of keeping this information around ourselves.
There's only one static registrar now, so there's no need for code to select
which one, just create the one and only.
Also unify this code between mtouch and mmp.
* [ObjCRuntime] Add support for getting the native ObjC class for a given System.Type without using the dynamic registrar.
* The static registrar now generates a table of any types that skipped
registration (which is currently used for generic types, such as
`NSArray<T>`), that allows us to look up the corresponding native type.
* In Runtime.Class now look in the tables generated by the static registrar to
find the native ObjC class for any given System.Type.
* Store the results in a dictionary so that the lookup isn't slower than
before (in fact it's ~4x faster now).
* [registrar] Elevate debug spew into a proper error.
* [registrar] Don't process 64bit-only skipped types on 32-bits.
This also requires fixing the registrar's parsing of the new [iOS] and [Mac]
availability attributes
* [linker] Optimize calls to BlockLiteral.SetupBlock to inject the block signature.
Optimize calls to BlockLiteral.SetupBlock[Unsafe] to calculate the block
signature at build time, and inject it into the call site.
This makes block invocations 10-15x faster (I've added tests that asserts at
least an 8x increase).
It's also required in order to be able to remove the dynamic registrar code in
the future (since calculating the block signature at runtime requires the
dynamic registrar).
* [mtouch/mmp] Add support for reporting errors/warnings that point to the code line causing the error/warning.
Add support for reporting errors/warnings that point to the code line causing
the error/warning by adding ErrorHelper overloads that take the exact
instruction to report (previously we defaulted to the first line/instruction
in a method).
* [tests] Add support for asserting filename/linenumber in warning messages.
* Make all methods that manually create BlockLiterals optimizable.
* [tests] Create a BaseOptimizeGeneratedCodeTest test that's included in both XI's and XM's link all test.
* [tests] Add link all test (for both XI and XM) to test the BlockLiteral.SetupBlock optimization.
* [tests] Add mtouch/mmp tests for the BlockLiteral.SetupBlock optimization.
* [tests][linker] Make the base test class abstract, so tests in the base class aren't executed twice.
* [tests][linker] Don't execute linkall-only tests in linksdk.
The optimization tests only apply when the test assembly is linked, and that
only happens in linkall, so exclude those tests in linksdk.
* [tests][mmptest] Update test according to mmp changes.
Fixes these test failures:
1) Failed : Xamarin.MMP.Tests.MMPTests.MM0132("inline-runtime-arch")
The warning 'MM0132: Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.' was not found in the output:
Message #1 did not match:
actual: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.'
expected: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.'
Message #2 did not match:
actual: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.'
expected: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.'
2) Failed : Xamarin.MMP.Tests.MMPTests.MM0132("foo")
The warning 'MM0132: Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.' was not found in the output:
Message #1 did not match:
actual: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.'
expected: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.'
Message #2 did not match:
actual: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.'
expected: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.'
* [tests][linker] Fix typo.
Fixes this test failure:
1) SetupBlock_CustomDelegate (Linker.Shared.BaseOptimizeGeneratedCodeTest.SetupBlock_CustomDelegate)
Counter
Expected: 1
But was: 2
* [registrar] Minor adjustment to error message to match previous (and better) behavior.
Fixes this test failure:
1) Failed : Xamarin.Registrar.GenericType_WithInvalidParameterTypes
The error 'MT4136: The registrar cannot marshal the parameter type 'System.Collections.Generic.List`1<U>' of the parameter 'arg' in the method 'Open`1.Bar(System.Collections.Generic.List`1<U>)'' was not found in the output:
Message #1 did not match:
actual: 'The registrar cannot marshal the parameter type 'System.Collections.Generic.List`1<Foundation.NSObject>' of the parameter 'arg' in the method 'Open`1.Bar(System.Collections.Generic.List`1<U>)''
expected: 'The registrar cannot marshal the parameter type 'System.Collections.Generic.List`1<U>' of the parameter 'arg' in the method 'Open`1.Bar(System.Collections.Generic.List`1<U>)''
* [docs] mmp shows MM errors/warnings.
* [docs] Improve according to reviews.
* [tests] Fix merge failure causing test duplication.
* [registrar] Register models in the static registrar.
This also means we need to quiet a few types of warnings:.
* Models declares virtual methods of required protocol members. We don't
export virtual methods (only when they're overridden are they exported),
which results in numerous warnings about protocol members not being
implemented:
Xamarin.Mac.registrar.mobile.x86_64.m:37827:17: warning: method 'deviceBrowserView:selectionDidChange:' in protocol 'IKDeviceBrowserViewDelegate' not implemented [-Wprotocol]
@implementation ImageKit_IKDeviceBrowserView__IKDeviceBrowserViewDelegate {
^
/Applications/Xcode92.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/Quartz.framework/Frameworks/ImageKit.framework/Headers/IKDeviceBrowserView.h:29:1: note: method 'deviceBrowserView:selectionDidChange:' declared here
- (void)deviceBrowserView: (IKDeviceBrowserView *)deviceBrowserView selectionDidChange: (ICDevice *)device;
* These two are the same as above, just for properties instead of methods.
Xamarin.Mac.registrar.mobile.x86_64.m:31988:17: warning: auto property synthesis will not synthesize property 'boundingMapRect' declared in protocol 'MKOverlay' [-Wobjc-protocol-property-synthesis]
@implementation MKOverlay {
^
/Applications/Xcode92.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/MapKit.framework/Headers/MKOverlay.h:24:43: note: property declared here
@property (nonatomic, readonly) MKMapRect boundingMapRect;
^
Xamarin.Mac.registrar.mobile.x86_64.m:32002:1: note: add a '@synthesize' directive
@end
^
Xamarin.Mac.registrar.mobile.i386.m:28957:17: warning: property 'repeatCount' requires method 'repeatCount' to be defined - use @synthesize, @dynamic or provide a method implementation in this class implementation [-Wobjc-property-implementation]
@implementation CAMediaTiming {
^
/Applications/Xcode92.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/QuartzCore.framework/Headers/CAMediaTiming.h:58:17: note: property declared here
@property float repeatCount;
^
* [AVFoundation] Special-case AVCaptureDataOutputSynchronizer[Delegate] in the registrar for macOS.
This class and protocol were incorrectly added to our macOS bindings, but
since we can't remove them because it would break backwards compatibility, we
must skip them manually in the registrar, since the registrar would otherwise
produce uncompilable code:
In file included from Xamarin.Mac.registrar.full.x86_64.m:2:
./Xamarin.Mac.registrar.full.x86_64.h:2929:63: error: 'AVCaptureDataOutputSynchronizerDelegate' is unavailable: not available on macOS
@interface AVCaptureDataOutputSynchronizerDelegate : NSObject<AVCaptureDataOutputSynchronizerDelegate> {
^
/Applications/Xcode92.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/AVFoundation.framework/Headers/AVCaptureDataOutputSynchronizer.h:101:11: note: 'AVCaptureDataOutputSynchronizerDelegate' has been explicitly marked unavailable here
@protocol AVCaptureDataOutputSynchronizerDelegate <NSObject>
^
In file included from Xamarin.Mac.registrar.mobile.x86_64.m:2:
./Xamarin.Mac.registrar.mobile.x86_64.h:3370:63: error: 'AVCaptureDataOutputSynchronizerDelegate' is unavailable: not available on macOS
@interface AVCaptureDataOutputSynchronizerDelegate : NSObject<AVCaptureDataOutputSynchronizerDelegate> {
* [AVFoundation] Stub out AVCaptureDataOutputSynchronizer[Delegate] on macOS.
AVCaptureDataOutputSynchronizer[Delegate] were incorrectly added to our macOS
bindings, which makes the static registrar's life difficult. So remove those
bindings, and re-implemented them as normal classes, without any attributes,
which makes the static registrar ignore them (to a certain extent: enough to
not generate uncompilable code at least).
* [registrar] Remove more model exclusion code.
* [xtro] Update ignored entries.
You were the preprocessor we wished C# had natively
Removing PMCS requires these changes:
* Remove XamCore from src/
* Remove XamCore from tools/
* Remove XamCore from runtime/
* nint/nuint enum conversion
* _compat_ enum conversion
* NSAction conversion
* Hand fix single API incorrectly converted by PMCS to unbreak compatibility
- Due to a bug in PMCS, the nuint was incorrectly converted in this API.
- However, as that ship as sailed, we must "fix" it until XAMCORE_4_0
* Update readme
* Bump macios-binaries
Converting to and from smart enums and their corresponding native value
requires knowing the conversion function, since each smart enum has its own
conversion function.
The dynamic registrar can do this at runtime, but it's something that can be
computed in the static registrar at build time, so do that. The static
registrar will now embed the metadata token (as a token reference) in the
generated code, which can be used at runtime to find the conversion method,
without requiring anything from dynamic registrar.
This requires some refactoring in the conversion methods to allow passing more
information around (the `context` parameter in the conversion functions, which
the smart enum conversion methods now use for the token reference).
It turns out this is a massive improvement (although the scenarios where this
is relevant are rare): a simple test case [1] is 300x faster (from ~30s to
0.1s).
[1]: https://gist.github.com/rolfbjarne/961af28d1c2727b256fbcdfd6aa65e98
It seems Apple started shipping CoreNFC headers some time (in a later beta)
after we first implemented (which was Xcode 9 beta 1).
Xcode 9.0, 9.1 and 9.2 all contain the exact same NFC headers (CoreNFC was
introduced with Xcode), so no version checks should be needed when removing
this exclusion.
* [ObjCRuntime] Add a BindingImplAttribute.
* [linker] Make ProviderToString an extension method on ICustomAttributeProvider to make it more discoverable.
* [generator] Use [BindingImpl] instead of [CompilerGenerated].
The entire diff is big (89MB), so it can't be gisted. However, most of it is
either removal of `using System.Runtime.CompilerServices;` or the change from
`[CompilerGenerated]` to `[BindingImpl (...)]` like this:
https://gist.github.com/rolfbjarne/8bfda3ed37b956d0342a1c1e9b079244
If I remove those parts of the diff, there's nothing significant left:
https://gist.github.com/rolfbjarne/4156164d6bdb1376366200394eb8a091
* [linker] Teach the linker about the new [BindingImpl] attribute.
In addition to the existing logic where the linker would optimize some
[CompilerGenerated] code (sometimes with additional requirements), it will now
also optimize all [BindingImpl (Optimizable)] code (without any additional
requirements).
* [tests] Add tests to make sure [BindingImpl (Optimizable)] works as expected.
* [linker] Check for [BindingImpl] before [CompilerGenerated] and stop checking for [CompilerGenerated] in XAMCORE_4_0.
Check for [BindingImpl] before checking for [CompilerGenerated], since the
former is more common.
Also stop checking for [CompilerGenerated] (at least to mean that code is
optimizable) in our next non-compatible evolutionary leap (XAMCORE_4_0):
* [introspection] Impl a better typo check.
The SharedStatic class is a leftover from when there were two static
registrars: the old one (OldStaticRegistrar) and the new one
(StaticRegistrar).
Since there's only one static registrar left (the old one died some time ago),
all the SharedStatic code can be put into the StaticRegistrar class.
There are no functional changes in this PR, only this refactoring.