This also centralize other interpreter checks and options in the same
location (making it easier to read / update).
* Warn and switch the REPL if the interpreter is enabled on simulator
Why ? It's confusing to build the same code using different options for
simulator and devices. This is what happens if you try to use features
like `dynamic` or `System.Reflection.Emit`.
So instead of an error, we warn that the interpreter is not supported
and switch to the existing REPL mode.
The JIT remains the only option for the simulator but it allows testing
features without a device.
* Fail early if the interpreter is used on 32bits [1]
The current interpreter only works on 64 bits (so ARM64). However the
error won't be reported, back to the developer, until deployment time.
This temporary [1] fix spot the condition very early and report an error
```
error MT0099 : Internal error : The interpreter is currently only available for 64 bits.
```
instead of the current one at deploy time
```
IncorrectArchitecture: Failed to find matching arch for 32-bit Mach-O input file /private/var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.tNKDlx/extracted/X.app/X
error MT1006: Could not install the application 'X.app' on the device 'Mercure': AMDeviceSecureInstallApplicationBundle returned: 0xe8000087 (kAMDIncorrectArchitectureError).
Application could not be uploaded to the device.
```
[1] https://github.com/mono/mono/issues/9871
* [tests] Fix/renumbered MT0138
The test was using simulator + interpreter which is not _really_
possible, we use REPL in that case - so we're now checking if
assemblies were specified with `--interpreter` to cover both cases.
Also 0138 was already used by `mmp` and the warning was **not**
registered or documented in the errors documents. To avoid
confusion it has been renumbered to 0142 and documented.
* [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.
In both cases we use a different binaries for a few assemblies. They
include support for SRE and a few other things that are not normally
usable on iOS. That's totally fine and not something that can be fixed
(unless you stop using the feature). So this PR simply ignore that
specific case so we don't warn about things that can't be changed (and
are not a problem)
E.g.
```
Warning MT0109: The assembly 'mscorlib.dll' was loaded from a different path than the provided path (provided path: /Users/poupou/git/intr/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/mscorlib.dll, actual path: /Users/poupou/git/intr/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/lib/mono/Xamarin.iOS/repl/mscorlib.dll). (MT0109) (XXX)
Warning MT0109: The assembly 'System.Core.dll' was loaded from a different path than the provided path (provided path: /Users/poupou/git/intr/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.Core.dll, actual path: /Users/poupou/git/intr/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/lib/mono/Xamarin.iOS/repl/System.Core.dll). (MT0109) (XXX)
Warning MT0109: The assembly 'System.dll' was loaded from a different path than the provided path (provided path: /Users/poupou/git/intr/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.dll, actual path: /Users/poupou/git/intr/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/lib/mono/Xamarin.iOS/repl/System.dll). (MT0109) (XXX)
Warning MT0109: The assembly 'System.Xml.dll' was loaded from a different path than the provided path (provided path: /Users/poupou/git/intr/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.Xml.dll, actual path: /Users/poupou/git/intr/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/lib/mono/Xamarin.iOS/repl/System.Xml.dll). (MT0109) (XXX)
```
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)
Fix comparison so the XM profiles do not report _inexistent_ changes for `_Attribute`, `_EventInfo` and `_Exception`. That noise makes it harder to review the diffs (for us) and is incorrect in our published API diffs (for release notes).
Also
* Delete .unzip.stamp on clean
* Skip classic XM diff (binaries won't change)
Reenable the tests and ensure that the failing ones on Modern are
ignored. The bcl tests on mac os x can now make a diff between the
version (Moder/Full) to ignore files so that tests that work in a
version are not ignored in the other one.
Fixes https://github.com/xamarin/maccore/issues/1200
* 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.
The removal of the XML files broke the comparison with the previous
commit. It did NOT fail the original PR because the targets were
in the previous commit.
And it will fail this PR because the previous commit still does not
have the targets - but it _should_ be fine, once merged, for all
future PR.
Fixes https://github.com/xamarin/maccore/issues/1452
* [XHarness] Ensure we do a nuget restore on bcl imported tests. Fixes#5383
We need to ensure that a nuget restore is done, otherwise we might have
build issues with missing libs.
Fixes https://github.com/xamarin/xamarin-macios/issues/5383
Instead download the assemblies (part of existing bundle.zip) of the
current release and generate the XML locally (no storage in github)
before doing the diff against the newer, just built, assemblies.
reference: https://github.com/xamarin/xamarin-macios/issues/4891
* We only need to do a runtime check on watchOS.
* On watchOS assume we're on a ARM64-based CPU as long as we're not on a
ARMv7k CPU.
Fixes an issue where we failed to detect a 64-bit iOS CPU as ARM64-based (in
particular iPhone X's ARM64v8).
The Mono AOT compiler maintains a set of signatures of compiled methods.
Those signatures are necessary to emit wrappers to enable the transition
from interpreter->AOT code. Thus, they must be collected for each
assembly.
* Improve the behavior when we fail to download the .dvtdownloadableindex file
to report a "Not Found" if we get a "Forbidden" (403) response, since that's
what it really is.
* Improve the behavior when we fail to download the .dvtdownloadableindex file
to check if the requested simulators are already installed instead of always
failing. This makes it possible to manually install the required simulators
if needed (Apple might not have published simulators for the Xcode version
we're using), and this would allow any checks to pass if the required
simulators are already installed.
* Improve the code to modify the PackageInfo XML to not use simple string
replacement (it's too fragile), use proper XML parsing instead.
* Fix "time left" math, I have no idea what my previous math was doing.
Clang will automatically compile .bc files into object code if needed, but
it's done serially. If we do the compilation ourselves, it'll be parallelized.
This makes the dontlink tests build in half the time when building for watchOS
/ Release (it drops from ~15 minutes to ~7 minutes).
The AOT compiler uses the 'outfile' as the base for a temporary .bc file. If
it's not set, the path to the assembly is used as the base instead. This does
not work if we compile the same assembly to multiple architectures (for
instance armv7k+arm64_32), because the temporary file will clash between those
AOT compilations.
This is not a problem for iOS (armv7+armv7s) because we don't compile to
bitcode (.bc files) on iOS.
* [mtouch] Don't use the native linker to create fat executables.
Don't use the native linker to create fat executables, instead link each
architecture separately, and then manually lipo everything together at the
end. This requires a few changes since we need to keep track of the linker
flags per architecture.
The problem is that bitcode files (.bc) do not correspond with a particular
architecture, so the linker can't distinguish between .bc files for armv7k and
.bc files for arm64_32. So if we pass all together to the linker, the linker
will add all .bc files to both architectures, thus duplicating everything (and
the linking fails with duplicate symbols errors).
* [mtouch] Fix building symlinked simulator executables.
* [mtouch] Fix several assumptions about each Target only producing a single executable.
The current code did not consider that overrides could be swept later,
if unused/unmarked by the linker, so we were missing opportunities to
make methods as final.
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
Fixes this warning:
tools/bcl-test-importer/BCLTestImporter/BCLTestProjectGenerator.cs(19,17): warning CS0414: The field 'BCLTestProjectGenerator.iOSReleasePattern' is assigned but its value is never used
* 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.
* Make PreserveSmartEnumConversionsSubStep use error codes that are not
already used elsewhere: this isn't obvious at first, but all
ExceptionalSubStep errors use a range of error numbers (10 numbers from NNN0
to NNN9), so we need to reserve that entire range. In this case there were
other errors using some of the numbers of the range for PreserveSmartEnumConversionsSubStep.
* Make sure there are anchor links for all the variations of each ExceptionalSubStep error.
Rework BCL test importation to generate projects that won't compile instead of
giving up completely in case of generation failure.
This means that xharness can still be used for non-BCL tests even if the
generation of the BCL tests fail.
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.
Sometimes we just Log a string without any format arguments. This works fine,
until the string comes from the user, and happen to contain braces, in which
case an invalid format exception is thrown.
Adding Log overloads that doesn't take format arguments (nor formats its
input) avoids this problem.
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.
The small typo made the test projects from mac and ios/tvos/watchos be
in different nodes in the xhanress web page which is ugly. They now wil
appear in the same node.
All the failing tests have been ignored. There are a large number of
tests ignored on the watchOS platform beacuase atm the iOS test dll is
used.
Fixes https://github.com/xamarin/maccore/issues/1135
As with other tests, this have been added because they were present when
we built the test assemblies locally, but they are not present in the
Mono SDK.
Fixes https://github.com/xamarin/maccore/issues/1132
As with other tests, this assembly was added when we built the tests in
the iOS makefile, but they are not present in the Mono SDK.
Fixes https://github.com/xamarin/maccore/issues/1140
Before
```
clang : error : no such file or directory: '/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/usr/lib/libmono-ee-interp.a'
clang : error : no such file or directory: '/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/usr/lib/libmono-icall-table.a'
clang : error : no such file or directory: '/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/usr/lib/libmono-ilgen.a'
error MT5209 : Native linking error : clang: error: no such file or directory: '/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/usr/lib/libmono-ee-interp.a'
error MT5209 : Native linking error : clang: error: no such file or directory: '/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/usr/lib/libmono-icall-table.a'
error MT5209 : Native linking error : clang: error: no such file or directory: '/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/usr/lib/libmono-ilgen.a'
MTOUCH : error MT5202: Native linking failed. Please review the build log.
0 Warning(s)
7 Error(s)
```
After
```
MTOUCH : error MT0141: The interpreter is not supported in the simulator. Do not pass --interpreter when building for the simulator.
0 Warning(s)
1 Error(s)
```
We can't share native code between apps and app extensions if the interpreter
settings differ between them, so detect this scenario and automatically
disable native code sharing.
Fixes https://github.com/xamarin/xamarin-macios/issues/5365.
Fixes this problem:
The following files were modified, and they shouldn't have been:
/Users/builder/jenkins/workspace/xamarin-macios-pr-builder/src
which shouldn't be reported, since the "file" in question is a directory.
Reference: https://github.com/xamarin/xamarin-macios/pull/5355#issuecomment-452400517
* [xibuild] Add support for /verbose, and use it accordingly.
Also stop using xibuild when it's not needed.
* Use the same verbosity for xibuild as we do for xbuild/msbuild.
This PR adds support to the use of *.ignore files for iOS/tvOS/WatchOS. The files are very similar to those that are use in xtro. We have:
* common-{TestProjectName}.ignore: For those tests that fail in all platforms.
* tvOS-{TestProjectName}.ignore: For tvOS specific failures.
* watchOS-{TestProjectName}.ignore: For watchOS specific failures.
* iOS-{TestProjectName}.ignore: for iOS specific projects.
Two test projects that were ignored previously have been added to show that the code does as advertised:
* SystemDataXunit: xUnit test project example. Fixes https://github.com/xamarin/maccore/issues/1131
* SystemServiceModelWebTests: NUnit test project example. Fixes https://github.com/xamarin/maccore/issues/1137
The files take the name of the failing tests, although we do support ignoring by class/namespace and other combinations, that would make the *.ignore files format more complicated and it is not worth it.
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.
Only the arm64 slice are built for iOS 7.0 (because that's when arm64 was
introduced), the arm7(s) slices are built for iOS 6.0, which means it's safe
to ignore this warning.
Fixes https://github.com/xamarin/xamarin-macios/issues/5092.
We now download the ios Mono sdk which means that there is no need for
us to build the test assemblies on iOS, WatchOS and tvOS BUT we need to
do so for the Mac tests.
The change includes:
1. Use fo the downloaded test assemblies.
2. Removal of the dependency of building them in the tests.
3. Move back to using reflection for the project generation.
4. Remove the cached project details added in the workaround.
- 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
This change adds support to execute the tests provided by mono as assemblies.This includes:
1. App generation to run the bcl tests on modern and full.
2. Needed workaround to delay the compilation of the assemblies until we have them from the SDK.
3. All failing tests are ignored.
* [mtouch] do not strip assemblies when interpreter is used
* [xharness] add release mixed-mode configuration
* [xharness] enable debug mixed-mode config for mscorlib
* [mtouch] add link to mono issue
- https://github.com/xamarin/xamarin-macios/issues/4435
- A common enough breakage in our handling of native references is if you have
two native libraries with dependencies (with rpath) between them that get copied into MonoBundle
- We did not add rpath to this location so we would not resolve them
- This is a behavior change, as anything that touches library resolution in mmp, but should be safe enough
- Add 2 ignore line for common swift libraries
* 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 to mono:2018-08
* Initialize Dependency Injector.
* Fix typo
* Fix llvm build
* Reflect latest X509CertificateImpl changes
* Use same compile flags also for link
Linking can fail if the minimum versions are different
* Bump mono
* Bump mono
* Assembly.LoadFile accepts only absolute path
* 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" >
* [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" >
* [tests] Reference GuiUnit_Net_4_5 using a project reference.
This makes sure GuiUnit is built when the main project is built.
* [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 mono to pick up hybrid suspend fixes
Pick up the 2018-08 backport (https://github.com/mono/mono/pull/10551)
of https://github.com/mono/mono/pull/10545
This should fix GC hangs when managed code runs on a GCD threadpool worker
thread.
* [builds] Fix target name in llvm36 provisioning
package-llvm-llvm36-32 isn't defined in external/mono/sdks/builds/llvm.mk,
but package-llvm36-llvm32 is.
* Revert "[builds] Fix target name in llvm36 provisioning"
This reverts commit b2338370cb.
* Revert "Fix llvm build"
This reverts commit f668561761.
* [mono-sdks] Necessary changes to unify the LLVM provisioning for both iOS and Android. (#4732)
* Bump mono
* Bump mono
* Revert "Use same compile flags also for link"
This reverts commit cf205396ff.
* Bump mono to pick up mono/mono@1a309a7b45
* [mmptest] System.Core doesn't depend on Mono.Posix in 2018-08
System.Core doesn't depend on Mono.Posix anymore since it's using the corefx
implementation of pipes now 0f0e31842f
* Bump mono and minimum system mono
* [security]: Make `SecCertificate` work with the latest runtime code.
* Fix the `NATIVE_APPLE_CERTIFICATE` logic; it should only be defined when
using `XAMARIN_APPLETLS` and not on watch.
* It is no longer allowed to construct `X509Certificate` from a native pointer,
the `X509Certificate(IntPtr)` and `X509Certificate2(IntPtr)` constructors now
throw an exception. Use `X509CertificateImplAppl` directly instead.
* Bump mono
* Bump VSmac min version to 7.7.0.1373
To pick up the fix for https://devdiv.visualstudio.com/DevDiv/_workitems/edit/658916/
Should fix the XM classic build failures
* Revert "Bump VSmac min version to 7.7.0.1373"
This reverts commit b2686bb152.
* Bump to a VSfM version that can build XM Classic projects.
* Bump mono system dependency
* Bump mono
Pick up mono/mono@1644a1a0 - fix for https://github.com/mono/mono/issues/10743
* Bump mono
* Bump mono
* [monotouch-test] Disable X509Certificate(byte[]) tests on watchOS (#4942)
* [monotouch-test] Disable X509Certificate(byte[]) tests on watchOS
* [tests] Add TestRuntime.AssertNotWatchOS()
* fixup WatchOS build
* Bump mono
* Bump mono
* [tests] Disable link-preserve-calendar-1 until we can upgrade it to be a Unified test.
See https://github.com/xamarin/xamarin-macios/pull/4596#issuecomment-428562076
for reference: mono's desktop API changed, the linker behavior the test is
verifying is only expected when using XM's Mobile profile.
* Bump mono
* Revert "[monotouch-test] Disable X509Certificate(byte[]) tests on watchOS (#4942)"
This reverts commit d003a9b918.
* Bump Mono.
* [security]: `NATIVE_APPLE_CERTIFICATE` should now be defined on watchOS as well.
* Mono 2018-08 requires macOS 10.9+, so Xamarin.Mac must as well.
* Bump min mono version for XM system apps.
Using a system mono < 5.18 results in a TypeLoadException:
Could not resolve type with token 01000032 from typeref (expected class 'Mono.ISystemDependencyProvider' in assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089')
* Bump guiunit to get updated min macOS version.
Commit list for mono/guiunit:
* mono/guiunit@9f67042 Bump min macOS version to 10.9.
* mono/guiunit@0c3159a [Harness] Fix exit code of 0 being reported in case of exceptions in the harness
* mono/guiunit@9b7497c Merge pull request #15 from mono/fix-more-warnings
* mono/guiunit@a264470 Fix more warnings
* mono/guiunit@dd094e7 Merge pull request #14 from mono/fix-warnings
* mono/guiunit@b3afede Fix build warnings
Diff: 1306b0d420...9f67042498
* [tests] More min macOS version setting to 10.9.
* Remove 10.7 & 10.8 availability attributes, since they're redundant now.
* Bump mono
* [2018-08][watchos] Use mono_dangerous_add_raw_internal_call for watchOS icalls (#5030)
* Add optional mono_dangerous_add_raw_internal_call to exports.t4
* Use mono_dangerous_add_raw_internal_call on watchOS for icall registration
Internal calls added with mono_dangerous_add_raw_internal_call run in GC Unsafe
mode under cooperative and hybrid suspend, whereas internal calls added with
mono_add_internal_call run in GC Safe mode since
mono/mono@5756ba4b46 in order for hybrid suspend
to be a transparent replacement for preemptive suspend (the old default). The
icalls in GC Unsafe mode have a responsibility not to block indefinitely
without manually performing a thread state transition to GC Safe mode, and in
return they avoid a thread state transition when the icall is invoked from a
managed method.
* [mmptest] Less hardcoding.
* Bump minimum mono one that has 'mono_dangerous_add_raw_internal_call'.
* Bump mono
* Bump system mono dependency
* Fixes building mono tests
* [ImageCaptureCore] Remove redundant availability attribute.
* [mtouch] Clear the MONO_THREADS_SUSPEND environment variable before calling the AOT compiler. Works around mono/mono#11765.
Visual Studio for Mac may set MONO_THREADS_SUSPEND, and this ends up confusing
the AOT compiler when compiling for watchOS.
So unset the environment variable before calling the AOT compiler.
Works around https://github.com/mono/mono/issues/11765.
* [xibuild] Auto-make if not already made.
Automatically make xibuild if it doesn't already exist.
Also fix the script:
* Use bash instead of sh, since it references BASH_SOURCE.
* Don't hide errors (-e).
* Fix shellcheck warnings
* Use $(..) instead of backticks, because backticks are strongly discouraged [1].
* Sprinkle quotes.
[1] For the curious: https://stackoverflow.com/a/4708569/183422
* Run make in the right directory.
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.
This makes it possible to build mmp (the partial static registrar code) with
the wrong system Xcode (which is not supported, but that doesn't mean we can't
try to make it mostly work to ease our lives).
I tried this in the xcode9 branch (PR #2588), and it didn't stick after the
xcode9 branch was merged to master.
I tried again a year later with the xcode10 branch (PR #4691), and once again
the commit didn't stick after the xcode10 branch was merged to master.
So now I'm trying to get this directly into master instead.
Let's see if it's still there when we branch for xcode11 next year...
Visual Studio for Mac may set MONO_THREADS_SUSPEND, and this ends up confusing
the AOT compiler when compiling for watchOS.
So unset the environment variable before calling the AOT compiler.
Works around https://github.com/mono/mono/issues/11765.
* [Xharness] Add a workaround to not build the xunit tests when not needed.
This is a workaround that does not use reflection to build the bcl test
projects. We need this until we have complete support of using mono as
an SDK.
* [runtime] Clean up public symbols. Fixes#5124.
Clean up public symbols, by:
* Symbols that don't need to be public (most of them), can be private.
* Prefix all public symbols with `xamarin_`.
* Add a test to ensure we don't introduce new public symbols.
* Use C symbols instead of mangled C++ symbols, since those are easier to
handle in the test.
This minimizes the chance of getting into a symbol clash with another native library.
Fixes https://github.com/xamarin/xamarin-macios/issues/5124.
* Some test fixes.
Only build the BCL tests when we need them, because we can't build them when
we're running the device tests (because we don't have a built source tree in
that case).
Since the test assemblies are required when generating the BCL projects, this
means we also delay creating the BCL projects until we need them.
* xibuild: New wrapper tool to run msbuild or managed executables
MSBuild supports fallback paths for projects imported using
`$(MSBuildExtensionsPath)`, but these must be specified explicitly in
the app.config of the main executable. There was a PR to allow use of
properties for this in the app.config, but that was not accepted
upstream.
This is required for being able to:
1. build projects with msbuild against the in-tree XI/XM build output
2. and to run nunit tests against the same.
For this we introduce a new tool, `xibuild`, based on XA's `xabuild`.
This supports the fallback paths to be specified via the environment variable
`MSBuildExtensionsPathFallbackPathsOverride`[1].
It essentially operates in 3 modes:
1. `xibuild -c /path/to/foo.exe`
Generates /path/to/foo.exe.config with the fallback paths inserted into that.
2. `xibuild -- /v:diag /path/to/project.csproj`
Runs msbuild with the arguments after `--` with a custom app.config based on
`MSBuild.dll.config`, with the fallback paths correctly inserted.
This is in a temporary file and the original config file is not touched.
3. `xibuild -t -- /path/to/managed_tool.exe args`
Generates `/path/to/managed_tool.exe.config` based on `MSBuild.dll.config` with
the fallback paths inserted, and runs `managed_tool.exe` with the arguments.
The default is to overwrite the config file.
But there is also a switch to merge it with an existing config file.
--
1. Value of the environment variable $MSBuildExtensionsPathFallbackPathsOverride
is prepended to any existing list of search paths in `MSBuild.dll.config`, IOW,
it takes precedence. So, the order of lookup becomes:
- Value of the property `$(MSBuildExtensionsPath)`
- Value of the environment variable `$MSBuildExtensionsPathFallbackPathsOverride`
- /Library/Frameworks/Mono.framework/External/xbuild on macOS
* Integrate use of `xibuild` with the tests
Update all uses of `msbuild` and invocations of tools like nunit that
might depend on using the in-tree builds to use `xibuild`.
* xibuild: Move help descriptions to OptionSet itself.
Mono know provides a set of testing assemblies that contain the tests to be ran in each of the supported platforms. This commit adds the following:
1. Two different runners that can be used to execute NUnit and xUnit tests.
2. The necessary glue to get xharness to run the new tests and report the results.
3. A new test that will ensure that if mono adds new tests, xharness will report failures if the tests are not run or not ignored.
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).
- https://github.com/xamarin/xamarin-macios/pull/4980 and the mono branch merge both added it
- However both copies were not the same, one was conditional and one added an extra -u option
- This collapses them into one check
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
Instead of a generic `MT0000` caused by an exception reading the magic
numbers of the binary framework file.
This was caused be uncompressing an archive, with a symlink, into a
file system that does not support symlinks (on Windows).
ref: https://github.com/xamarin/xamarin-macios/issues/5028
* 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.
Commit 996d90614b fixed the use of XML files. However it did not set the flags so if it's used in both XML and in code then the dictionary is being added twice, which throws an exception like
```
error MT2102: Error processing the method 'System.Boolean SignalGo.Shared.Helpers.ReflectionHelper/d__0::MoveNext()' in the assembly 'SignalGo.Shared.dll': An item with the same key has already been added. Key: System.String System.Reflection.ParameterInfo::get_Name()
```
reference: https://github.com/xamarin/xamarin-macios/issues/4978
* 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.
This means we'll get an empty diff if there are no generator changes, so
update the logic that detects/reports empty generator diffs.
Also there's no need to ignore mdbs anymore, since we don't create mdbs.
* XI references updated from `xcode10` (XI 12.0)
* XM references are not updated, we continue to compare with `d15.8`
* references_/* were temporary files that should not have been committed (old mistake)
* XI references updated from `xcode10` (XI 12.0)
* XM references are not updated, we continue to compare with `d15.8`
* references_/* were temporary files that should not have been committed (old mistake)
* XI references updated from xcode10 (XI 12.0)
* XM references are not updated, we continue 4.99.x previews
* references_/* were temporary files that should not have been committed (old mistake)
* 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.
* [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.
* 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.
This makes it possible to build mmp (the partial static registrar code) with
the wrong system Xcode (which is not supported, but that doesn't mean we can't
try to make it mostly work to ease our lives).
* Make sure mtouch.csproj builds using the same compiler arguments as the makefile used.
* Build mtouch.exe using msbuild in the makefile, and clean up the resulting unused make logic.
Partial fix for https://github.com/xamarin/xamarin-macios/issues/4384.
* Make sure mmp.csproj builds using the same compiler arguments as the makefile used.
* Clean up mmp.csproj by removing stuff that was left over from when it was a Xamarin.Mac project.
* Build mmp.exe using msbuild in the makefile, and clean up the resulting unused make logic.
Partial fix for https://github.com/xamarin/xamarin-macios/issues/4384.
* Make sure mtouch.csproj builds using the same compiler arguments as the makefile used.
* Build mtouch.exe using msbuild in the makefile, and clean up the resulting unused make logic.
Partial fix for https://github.com/xamarin/xamarin-macios/issues/4384.
* Make sure mmp.csproj builds using the same compiler arguments as the makefile used.
* Clean up mmp.csproj by removing stuff that was left over from when it was a Xamarin.Mac project.
* Build mmp.exe using msbuild in the makefile, and clean up the resulting unused make logic.
Partial fix for https://github.com/xamarin/xamarin-macios/issues/4384.
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
* [jenkins] Only XM apps with variations are Classic/32-bit apps, so adjust ignore logic accordingly. Fixes maccore issue 884.
Fixes https://github.com/xamarin/maccore/issues/884.
* [mmp] Fix passing -stdlib=libc++ to clang.
* [tests] Fix 32-bit XM issues.
* [xharness] Add support for building 32-bit XM apps by using Xcode 9.4.
* [xharness] Since xharness can now build 32-bit mac apps, enable them by default.
* Remove debug code.
* Remove unused variable.
* 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).
* [mtouch] Show warnings when we can't find referenced assemblies.
This would have helped track down #4235.
* Improve MT0137 warning to indicate the type of the attribute causing the warning.
Rename a method that clashes with a new method in a base class to avoid a
compiler warning about hidden inherited members.
Fixes:
xamarin-macios/tools/linker/MobileSweepStep.cs(41,26): warning CS0114: 'MobileSweepStep.SweepAssembly(AssemblyDefinition)' hides inherited member 'SweepStep.SweepAssembly(AssemblyDefinition)'. To make the current member override that implementation, add the override keyword. Otherwise add the new keyword.
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
Fixes:
xamarin-macios/external/mono/external/linker/linker/Linker.Steps/MarkStep.cs(310,60,310,73): error CS0117: 'Array' does not contain a definition for 'Empty'
Use libc++ instead of stdlibc++ for Xamarin.Mac too.
See 0d31720770 for more info.
Also revert a series of commits that bumps min macOS version from 10.7 to 10.9
* 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;
We write 'No change detected' to [platform]-api-diff.html, which means that
checking for an empty file to detect no changes when generating the container
api-diff.html doesn't work as intended.
So change the logic to check for the 'No change detected' string instead.
On my test project we were calling `IsArchEnabled` 334,713 times which
made the enumerator called enough to show on the memory usage (13MB),
even if each instance is only 40 bytes.
Caching the result makes the method called only 5 times.
* [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).
Sebastien Pouliot
Alexander Köplinger
Rolf Bjarne Kvinge
Manuel de la Pena
Bernhard Urban
Bernhard Urban
Chris Hamons
Marek Safar
Ankit Jain
Ludovic Henry
Martin Baulig
Alex Soto
Sebastien Pouliot
Martin Baulig
Jo Shields
Xamarin Jenkins User
Vincent Dondain
Miguel de Icaza