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.
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
* [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.
* [mtouch/mmp] Give users more control over optimizations, and share more code between mtouch and mmp.
1. Add an --optimize flag to mtouch/mmp that allows users to select which
optimizations to apply (or not). This makes it easier to add future
optimizations, and allow users to disable any optimization that causes
problems without having to disable many other features.
2. Share as much optimization code as possible between mtouch and mmp. This
immediately gives a benefit to mmp, which has three new optimizations only
mtouch had: NSObject.IsDirectBinding inlining, IntPtr.Size inlining and
dead code elimination.
This results in ~6kb of disk space saved for a linked Xamarin.Mac app:
* link sdk: [Debug][1], [Release][2]
* link all: [Debug][3], [Release][4]
Testing also verifies that monotouchtest ([Debug][5], [Release][6]) has not
changed size at all, which means that no default optimizations have changed
inadvertedly.
[1]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#link-sdk-mac--debug
[2]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#link-sdk-mac--release
[3]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#link-all-mac--debug
[4]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#link-all-mac--release
[5]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#monotouchtest-iphonedebug64
[6]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#monotouchtest-iphonerelease64
* [tools] Don't enable the IsDirectBinding optimization by default for Xamarin.Mac apps, it's not safe.
* Fix whitespace issues.
* [doc] Document optimizations.
* Officially support optimizations by adding them to the Versions.plist.
* [linker] Improve IntPtr.Size inliner + dead code eliminatior and add tests.
* Properly handle operands for the ldc_i4_s instruction (they're sbyte).
* Fix less-than condition to actually do a less-than comparison.
* Make sure to look up the bitness in the Target, not the Application, since
the Application's value will be incorrect when building fat apps (both
Is32Build and Is64Build will be true).
* Remove unnecessary checks for the IntPtr.Size inliner: this optimization
does not depend on other instructions than the IntPtr.get_Size call, so
remove the checks that verify surrounding instructions. This makes the
IntPtr.Size inliner kick in in more scenarios (such as the new tests).
* Add tests.
* [tests] Add mmp tests for optimizations.
* [tests] Fix XM optimization tests.
* [tests] Fix test build error.
* [mtouch] Make sure the xamarin_localized_string_format* functions are available in simlauncher. Fixes#3265.
Fixes https://github.com/xamarin/xamarin-macios/issues/3265.
* [mtouch] Add test for simlauncher symbols, add add more missing symbols.
* [mtouch][mmp] Report invalid debug symbols files. Fixes#3200
Try to read the assembly with symbols and, if that fails, warn and
fallback to loading them without symbols.
This fixes cases were it's not easy to update or delete (e.g. nuget)
bad symbols files - so this cannot be an error without causing a lot
of pain.
However it needs to be reported, otherwise it wont be fixed (by the
publisher) and it can limit the debugability of the application and
the usefulness of the stacktraces.
Finally merge most of the resolver's code between mtouch and mmp so
we don't have to fix such issue twice anymore.
note: this needs to be slightly updated once we get a version of cecil
that can give us a more precise error message.
Also bring Rolf's tests from
https://github.com/xamarin/xamarin-macios/pull/3079
reference:
https://github.com/xamarin/xamarin-macios/issues/3200
We can't trust Apple's native linker to pick the right (non private)
framework when an older TargetVersion is used. It just prefer what's
available - even if specified with a WeakFramework :(
That was already dealt with for applications. However the native linking
of the Xamarin.Sdk.framework (code sharing with extensions) is done with
the `LinkTask` instead of the `NativeLinkTask` so it did not have the
"auto correct" code.
Unit test added.
reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=61039
The parsing done by `System.Version` does not accept a major-only string,
e.g. providing "11" would throw an exception.
Since people generally refer version as iOS 11 (and not iOS 11.0) this
is, at best, a nuisance. Xcode toolchain accept "11" as a valid string.
The first part of message was updated to show both the option name and
the (user provided) value.
The 2nd part remain the text of the .net exception message, i.e. what
`Version.Parse` tells you when it validates the string. Seeing the input
value should make it more obvious for other, incorrect version strings.
reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=60280
* [mtouch/mmp/bgen] Add support for response files.
This is the first part of the fix for #56501.
https://bugzilla.xamarin.com/show_bug.cgi?id=56501
* [tests] Make sure no single argument starting with a '@' is passed to mtouch unless it's a response file.
--assembly-build-target takes arguments starting with '@', for instance:
--assembly-build-target @all=framework
which does not work anymore, because that's interpreted as a response file
(mtouch tries to read the file '@all=framework', which obviously doesn't
exist).
The fix is simple, don't put a space between the two arguments:
--assembly-build-target=@all=framework
* Add --root-assembly to mtouch/mmp and make the MSBuild tasks use this new option.
This makes it possible to pass root assemblies starting with `@` to mtouch/mmp
without getting mistaken for response files.
* [msbuild] Always use the command-line option that takes an equals or colon.
Always use the command-line option that takes an equals or colon instead of a
space.
Do either of these:
--foo=something
--foo:something
instead of this:
--foo something
so that `something` can start with an at (`@`) sign without being mistaken for
a response file.
* [msbuild] Fix tests according to recent task changes.
* Update the function name used to initialize libmono-profiler-log, its called mono_profiler_init_log () now.
* [builds] Pass --with-cross-offsets= to crosstv's configure.
* Bump mono to 2017-08.
* Bump mono to 2017-08.
* Force disable 'futimens' and 'utimensat' so that we build with Xcode 9.
This is also needed to build with Xcode 8.3 on High Sierra.
* Remove old AppleTls implementation.
* Bump mono.
* Bump mono to 2017-08.
* Bump mono to 2017-08
* Reenable link-keep-resources-2 test
- This reverts commit 76b759ef22.
- 2017-08 has linker fix
* Bump mono to 2017-10
* Revert "Bump mono to 2017-10"
This reverts commit bb7832724e.
* Bump system mono to 2017-10
* Bump embedded mono to 2017-10
* [runtime] reflect eglib move
9be68f8952
* bump mono
* [btouch] remove Security.Tls usage from test
* [mtouch tests] update the function name used to initialize libmono-profiler-log, its called mono_profiler_init_log () now.
see
ea4e4a9ef6
fixes:
```
1) Failed : Xamarin.MTouch.Profiling(tvOS)
_mono_profiler_startup_log
Expected: collection containing "_mono_profiler_startup_log"
But was: < "_mono_profiler_init_log" >
at Xamarin.MTouch.Profiling (Xamarin.Profile profile) [0x00106] in <511889694a624cc9a50e0e9b259b05c5>:0
2) Failed : Xamarin.MTouch.Profiling(watchOS)
_mono_profiler_startup_log
Expected: collection containing "_mono_profiler_startup_log"
But was: < "_xamarin_get_block_descriptor", "_mono_profiler_init_log" >
at Xamarin.MTouch.Profiling (Xamarin.Profile profile) [0x00106] in <511889694a624cc9a50e0e9b259b05c5>:0
```
* [mmptest] update log profiler options.
826558a4af
deprecated the dash prefix for the mlpd path.
`noallocs` or `nocalls` are not needed, neither of them are default anymore.
* [mmptest] fix link-keep-resources-2 test to cope with more corlib resources.
another corlib resource (mscorlib.xml) was added:
https://github.com/mono/mono/commit/11e95169e787#diff-2d1c64decd91d9a6e8842ab0f0e9438d
* Revert "[mmptest] fix link-keep-resources-2 test to cope with more corlib resources."
This reverts commit 350eb3c174.
* [XHarness] Add the Mono.Data.Tds tests.
* Address comments from rolf in the review.
* [mmp regresssion tests] bump mono linker, so mscorlib.xml gets stripped
the test was failing in that way:
> Executing link-keep-resources-2...
> [FAIL] i18n 4/2 data files present: charinfo.nlp, collation.core.bin, collation.tailoring.bin, mscorlib.xml
also update the output, because it's actually expected at least three
elements.
fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=59277
* bump mono
fixes crash in tvOS: https://github.com/mono/mono/pull/5812
* bump mono for updated BCL tests
see https://github.com/mono/mono/pull/5820
* [mono] set 2017-10 branch in .gitmodules
* [macos] Fix guiunit error on clean builds by depending on correct copy (#2912)
* [macos] Fix guiunit error on clean builds by depending on correct copy
- From a clean build making a BCL test would error due to the non-mobile guiunit not being built
- This was because the Makefile-mac.inc target was incorrect
- This was because xharness assumed that non variation based targets were always Modern
- However, BCL tests are Full, not Modern
* Code review change
* Swap to var to reduce diff
* Revert changes in the paths for GuiUnit.
* [XHarness] Add the System.IO.Compression bcl tests. (#2918)
* [XHarness] Add the System.IO.Compression bcl tests.
* [XHarness] Add bcl tests for System.IO.Compression.FileSystem. (#2924)
* [XHarness] Add the System.IO.Compression bcl tests.
* Ensure that resources are correctly copied in the bundles.
* [XHarness] Add bcl tests for System.IO.Compression.FileSystem.
* As per review, make the Mac test app name match the tests that are ran.
* [XHarness] Add Mono.CSharp tests on ios. (#2927)
* [XHarness] Add Mono.CSharp tests on ios.
* Bump mono to bring changes in the mono.csharp tests.
* [xtro-sharpie] fix TypeDefinition access due to Cecil change
* Bump mono
* bump mono
fixes
- https://bugzilla.xamarin.com/show_bug.cgi?id=60480
- https://bugzilla.xamarin.com/show_bug.cgi?id=60482
* bump mono
more fixes around conflicting paths when tests are run in parallel.
* Bump for mono/mono@2017-10
- https://bugzilla.xamarin.com/show_bug.cgi?id=60277
- Teach mmp and mtouch resolver to always ask for symbol reading from Cecil
- In most cases we explicitly load symbols (LoadReferencesStep) but when we don't rewritten assemblies don't match their pdb and we break debugging.
* [registrar] Remove useless interface.
* [registrar] Don't store LinkContext in the static registrar when in can be fetched from the Target. Partially fixes#59617.
This avoids a problem where our code would store null because LinkContext
wasn't created yet when the static registrar instance was created.
This fixes the missing error from bug #59617.
https://bugzilla.xamarin.com/show_bug.cgi?id=59617
* [registrar] Don't verify the SDK for protocol members. Partially fixes#59617.
It's not needed, because protocol members don't end up in the registrar output
anyway (and would thus not prevent the registrar code from compiling).
Classes that implement any protocol members would still run into the SDK
check, so this should not prevent real problematic code from being reported
either.
https://bugzilla.xamarin.com/show_bug.cgi?id=59617
* [tests][mtouch] Fix tests after registrar changes.
It does not make sense to create Xamarin.iOS projects that don't reference
Xamarin.iOS.dll, so make this an explicit error.
This fixes a NullReferenceException which could (when building for device, or
when not using simlauncher) occur, and instead shows the MT0123 error.
> MTOUCH : error MT0000: Unexpected error - Please file a bug report at http://bugzilla.xamarin.com
> System.NullReferenceException: Object reference not set to an instance of an object
> at Xamarin.Bundler.Target.GatherFrameworks () [0x00065] in /Users/builder/data/lanes/5024/152b654a/source/xamarin-macios/tools/common/Target.cs:122
> at Xamarin.Bundler.Target.ProcessAssemblies () [0x000c2] in /Users/builder/data/lanes/5024/152b654a/source/xamarin-macios/tools/mtouch/Target.cs:802
> at Xamarin.Bundler.Application.ProcessAssemblies () [0x0002f] in /Users/builder/data/lanes/5024/152b654a/source/xamarin-macios/tools/mtouch/Application.cs:1407
> at Xamarin.Bundler.Application.BuildManaged () [0x00001] in /Users/builder/data/lanes/5024/152b654a/source/xamarin-macios/tools/mtouch/Application.cs:831
> at Xamarin.Bundler.Application+<>c.<BuildAll>b__134_1 (Xamarin.Bundler.Application v) [0x00000] in /Users/builder/data/lanes/5024/152b654a/source/xamarin-macios/tools/mtouch/Application.cs:779
> at System.Collections.Generic.List`1[T].ForEach (System.Action`1[T] action) [0x00024] in <48b95f3df5804531818f80e28ec60191>:0
> at Xamarin.Bundler.Application.BuildAll () [0x00050] in /Users/builder/data/lanes/5024/152b654a/source/xamarin-macios/tools/mtouch/Application.cs:779
> at Xamarin.Bundler.Driver.Main2 (System.String[] args) [0x00481] in /Users/builder/data/lanes/5024/152b654a/source/xamarin-macios/tools/mtouch/mtouch.cs:1420
> at Xamarin.Bundler.Driver.Main (System.String[] args) [0x0000f] in /Users/builder/data/lanes/5024/152b654a/source/xamarin-macios/tools/mtouch/mtouch.cs:945
https://bugzilla.xamarin.com/show_bug.cgi?id=59798
Bug #59570 was a dupe of #58063 but was harder (than it should be) to
diagnose because the error did not point out which assembly had the
issue (requiring a whole, large, customer solution to confirm).
This adds a new MT2103 error which points to the assembly that could
not be read.
E.g. VSfM will now show
> Error MT2103: Error processing assembly 'Shim, Version=2.0.1.0, Culture=neutral, PublicKeyToken=c55ec16d10c4b366': System.NullReferenceException: Object reference not set to an instance of an object (MT2103) (...)
[1] https://bugzilla.xamarin.com/show_bug.cgi?id=59570
[2] https://bugzilla.xamarin.com/show_bug.cgi?id=58063
Apple rejects apps that links with the previously private IOSurface.framework.
We were not sure about this [1] and had it disabled (this is removed).
However another bug stopped our adjustment logic [2] from being executed. This
is needed since `clang` picks up the private framework if it does not find the
public one (even when asking for a weak framework),
[1] https://bugzilla.xamarin.com/show_bug.cgi?id=59201
[2] Added a while ago for JavascriptCore
* [msbuild] Re-added wildcard (*) expandsion for application-identifier in Entitlements.plist (#2186)
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=57119
* Bump mono (#2213)
* Framework tests were still binding non-linked Simple class which errors now (#2216) (#2218)
- Improve Makefile to rebuild when projects build with errors
* Bump mono to get cecil fix for bug #56808. (#2222)
https://bugzilla.xamarin.com/show_bug.cgi?id=56808
* [msbuild] Use @(ReferencePath) instead of @(ResolvedFiles) (#2188) (#2214)
This allows things to work on both xbuild and msbuild.
In xbuild, both lists are exactly the same and on msbuild,
only @(ReferencePath) exists.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=55147
* NSActivityOptions.IdleDisplaySleepDisabled had wrong value (#2232) (#2239)
This was due to an integer overflow. The original value was based on Int32
1 << 40 == 256
The correct value should be based on a UInt64.
1UL << 40 == 1099511627776
* [tests] Fix bug 57699 - [iOS]InternalsTest failure (Linkall) tests on device (#2243)
Strip native debugging symbols should not be checked for debug builds
* Bump mono to get fix for bug #57780.
https://bugzilla.xamarin.com/show_bug.cgi?id=57780
* Update .gitmodules
Change branch to d15-3 branch of mono
* Bump maccore to get fix for bug #55064.
https://bugzilla.xamarin.com/show_bug.cgi?id=55064
* [mono] Bump mono to get the head of cecil/mono-2017-04 and fix IsComObject #57919
Also fix#58789 [1], the typo in tools/mtouch/Tuning.cs showing in MT0000 errors
instead MT2102. That's already in master and d15-4
mono bump includes:
[2] commit 2a6502cee0df9de5198eafe7c8b5f6ac25106f34 (HEAD -> d15-3, origin/d15-3)
Merge: 02457c20fcf 5e05cafc6f1
Author: Luis Aguilera <luis.aguilera@xamarin.com>
Date: Fri Aug 18 10:04:06 2017 -0400
Merge pull request #5401 from marek-safar/com
[Marshal.IsComObject] Make this predicate return false instead of thr…
[3] commit 02457c20fcf57c0610e844d638eb1da82b5d1eb0
Merge: da80840ea55 73fd9a1b82e
Author: Luis Aguilera <luis.aguilera@xamarin.com>
Date: Fri Aug 18 09:59:06 2017 -0400
Merge pull request #5400 from spouliot/bump-cecil-58834-d15-3
[cecil] Bump to the head of the mono-2017-04 branch and pick the fix for bug #58834
References
[1] https://bugzilla.xamarin.com/show_bug.cgi?id=58789
[2] https://bugzilla.xamarin.com/show_bug.cgi?id=57919
[3] https://bugzilla.xamarin.com/show_bug.cgi?id=58834
* [mtouch] Put 'mono_profiler_startup_log' in the symbol list. Fixes#58778. (#2501)
We need the 'mono_profiler_startup_log' symbol when profiling is enabled, so
make sure to add the symbol to the correct list of symbols we need.
Previously we were passing `-u _mono_profiler_startup_log` to clang directly,
which is fine, but not complete, since it does not write the symbol to the
symbollist file (--symbollist=file), which means it wouldn't be preserved when
the MSBuild tasks strip the executable.
https://bugzilla.xamarin.com/show_bug.cgi?id=58778
* Bump versions for SR3
https://trello.com/c/EVze08ei
* Bump mono to include HttpClientHandler fix#44027https://trello.com/c/jYFXadH8/8-systemnethttp-close-request-stream-when-httpclienthandlerhttps://bugzilla.xamarin.com/show_bug.cgi?id=44027
* [mtouch/mmp] Set CultureInfo.CurrentCulture according to LANG.
This makes it easier to run mtouch/mmp under different locales when testing.
Unfortunately mono checks the system locale before checking LANG, which means
that there's no built-in way in macOS/mono to specify the current locale
without changing the system locale.
* [mtouch] Print verbosity using an invariant culture. Fixes#58849.
https://bugzilla.xamarin.com/show_bug.cgi?id=58849
* [mtouch/mmp] Fix error code.
* [mtouch/mmp] Log/warn when we set the current language.
We need the 'mono_profiler_startup_log' symbol when profiling is enabled, so
make sure to add the symbol to the correct list of symbols we need.
Previously we were passing `-u _mono_profiler_startup_log` to clang directly,
which is fine, but not complete, since it does not write the symbol to the
symbollist file (--symbollist=file), which means it wouldn't be preserved when
the MSBuild tasks strip the executable.
https://bugzilla.xamarin.com/show_bug.cgi?id=58778
* [mtouch] Don't allow building for 32-bit when deployment target is >= 11. Fixes#57966.
Also bump maccore to get an mlaunch error for launching a 32-bit app in a 64-bit-only simulator.
https://bugzilla.xamarin.com/show_bug.cgi?id=57966
* [tests][msbuild] Make sure all Info.plists have deployment targets.
Otherwise we get different behavior (32-bit allowed or not) depending on which
Xcode is used to build.
* [mtouch] Default to 64-bit arch if not specified and targeting iOS 11+.
* [tests] Tweak tests to either specify a deployment target < 11 or not build a 32-bit arch.
- Fixed the generator to avoid `ARKit/ARSCNViewDelegate.g.cs(189,43): error CS0432: Alias 'Iglobal' not found`.
- ARPointCloud can be tested with this [sample](https://github.com/VincentDondain/ios-testcases/tree/master/ARPointCloudTest).
It requires deploying on devices and moving the camera around so ARKit can return some points. After 5 seconds it should print the points.
- Fixed intro tests.
- Fixed `bindings-generator.cs` for new simd types.
HFS normalizes filenames to Form D when files are stored. This means that an
assembly whose assembly name is stored in Form C might be stored in a file
whose filename is Form D (which you'll get if you use the Form C filename).
However, this is a problem when we've already loaded an assembly and if we
doesn't take normalization into account: we check the cache based on the
filename, but store in the cache based on the assembly name. If those two uses
different normalization schemes, bad things (bug #57266) happen.
So in these scenarios normalize strings before comparing them.
https://bugzilla.xamarin.com/show_bug.cgi?id=57266
- Update Versions-ios and Versions-mac file too.
- Bump maccore and maciostools to the xcode9 branch.
- [builds] Force disable 'futimens' and 'utimensat' so that we build with Xcode 9.
- [builds] 'system' is not available on iOS (simulator).
- [runtime] Fix: cannot initialize a variable of type 'char *' with an rvalue of type 'const char *'
- Prevented building xcode9 branch, see: https://jenkins.mono-project.com/job/xamarin-macios-pr-builder/3886/console
```
runtime.m:1122:9: error: cannot initialize a variable of type 'char *' with an rvalue of type 'const char *'
char *last_sep = strrchr (info.dli_fname, '/');
```
- [registrar] Apple removed a header, so don't include it anymore.
- [mtouch] Don't run the partial static registrar for tvOS.
The generated output doesn't compile because Apple forgot to ship headers for
the ExternalAccessory framework in their tvOS simulator SDK.
* [mtouch] Improve how we make sure native symbols aren't stripped away. Fixes#51710 and #54417.
* Refactor required symbol collection to store more information about each
symbol (field, function, Objective-C class), and in general make the code
more straight forward.
* Implement support for generating source code that references these symbols,
and do this whenever we can't ask the native linker to keep these symbols
(when using bitcode). Additionally make it possible to do this manually, so
that the source code can be generated for non-bitcode platforms too (which
is useful if the number of symbols is enormous, in which case we might
surpass the maximum command-line length).
* Also make it possible to completely ignore native symbols, or ignore them on
a per-symbol basis. This provides a fallback for users if we get something
right and we try to preserve something that shouldn't be preserved (for
instance if it doesn't exist), and the user ends up with unfixable linker
errors.
* Don't collect Objective-C classes unless they're in an assembly with
LinkWith attributes. We don't need to preserve Objective-C classes in any
other circumstances.
* Implement everything for both Xamarin.iOS and Xamarin.Mac, and share the
code between them.
* Remove previous workaround for bug #51710, since it's no longer needed.
* Add tests.
https://bugzilla.xamarin.com/show_bug.cgi?id=54417https://bugzilla.xamarin.com/show_bug.cgi?id=51710
* [mtouch] Make sure to only keep symbols from the current app when code sharing.
This fixes a build problem with the interdependent-binding-projects test when
testing in Today Extension mode.
In 11390f119c we stopped setting the force flag
when the cache was invalid, because we'd delete the cache anyway, and it was
determined that deleting the cache was enough.
Unfortunately it's not, because some output is not in the cache, and might not
get correctly updated.
Scenario:
* User builds app.
* User changes some build option (for instance switching off incremental
builds).
* User does an insignificant change in a source file for the executable
process.
* User builds app again (without cleaning). This will rebuild the exe, but
since the change was insignificant, all the IL, except the MVID, would
remain identical.
* mtouch would see that the command-line options changed, and invalidate the
cache. This would delete the cache, and everything would be rebuilt,
including AOT-compiling the assemblies again.
* When the time came for mtouch to copy assemblies to the app directory,
mtouch would realize that the existing .exe in the app (which was not
deleted because it's not in the cache, but the actual output directory) was
only insignificantly different (only the MVID was different, which our cache
logic knows to ignore when comparing assemblies), so it wouldn't copy the
.exe to the .app.
* At runtime we'd assert, because the MVID in the aot-compiled code was
different from the MVID in the assembly:
error: Failed to load AOT module '(null)' while running in aot-only mode: doesn't match assembly.
* The exact assert varies depending on which build option changed. Other
variations:
Failed to load AOT module '(null)' while running in aot-only mode: compiled against GC (4, while the current runtime uses GC sgen)
* Assertion at /Users/builder/data/lanes/4691/0719ced1/source/xamarin-macios/external/mono/mono/metadata/metadata.c:1118, condition `idx < t->rows' not met
Because of this I'm reverting 11390f119c, and
once again setting the force flag when the cache is invalid. It might be
overkill, but it's the safest option (cache invalidation is after all the only
hard problem in computer science), and bugs are very annoying and
timeconsuming to track down.
https://bugzilla.xamarin.com/show_bug.cgi?id=54973
This change introduces the export of create_classes methods as objc compatible, without enforcing Objective-C++ as the development language for custom registrar embedders by moving the stringbuilder flushing inside the extern "C" block.
Mark the generated linking code as extern "C" too and also change the return type of xamarin_create_classes_Xamarin_Mac to void in mmp generation, as it was mistakenly set to int.
When converting strings to a sequence of bytes, we can't just cast chars to
ints, and write that, because non-ascii characters will resulting values
outside the byte range.
Instead explicitly convert the string to a UTF8 byte array, and process that.
https://bugzilla.xamarin.com/show_bug.cgi?id=56876
Since ee4c07b9ce we treat config files like
debug files and assemblies (they're all touched after the linker is done).
This means we also need to apply the same logic when copying config files as
we do when copying debug files and assemblies (only copy if the contents are
different), otherwise we end up rebuilding too much.
This fixes a few test failures:
1. Failed : Xamarin.MTouch.RebuildTest_WithExtensions("single","",False,System.String[])
single
Expected: <empty>
But was: < "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory294/testServiceExtension.appex/testServiceExtension is modified, timestamp: 5/29/2017 6:21:25 PM", "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory294/testServiceExtension.appex/testServiceExtension.aotdata.armv7 is modified, timestamp: 5/29/2017 6:21:24 PM", "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory294/testServiceExtension.appex/testServiceExtension.dll.config is modified, timestamp: 5/29/2017 6:21:24 PM" >
2. Failed : Xamarin.MTouch.RebuildTest_WithExtensions("dual","armv7,arm64",False,System.String[])
dual
Expected: <empty>
But was: < "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory298/testServiceExtension.appex/testServiceExtension is modified, timestamp: 5/29/2017 6:22:44 PM", "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory298/testServiceExtension.appex/testServiceExtension.aotdata.arm64 is modified, timestamp: 5/29/2017 6:22:43 PM", "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory298/testServiceExtension.appex/testServiceExtension.aotdata.armv7 is modified, timestamp: 5/29/2017 6:22:43 PM", "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory298/testServiceExtension.appex/testServiceExtension.dll.config is modified, timestamp: 5/29/2017 6:22:37 PM" >
3. Failed : Xamarin.MTouch.RebuildTest_WithExtensions("llvm","armv7+llvm",False,System.String[])
llvm
Expected: <empty>
But was: < "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory302/testServiceExtension.appex/testServiceExtension is modified, timestamp: 5/29/2017 6:23:38 PM", "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory302/testServiceExtension.appex/testServiceExtension.aotdata.armv7 is modified, timestamp: 5/29/2017 6:23:37 PM", "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory302/testServiceExtension.appex/testServiceExtension.dll.config is modified, timestamp: 5/29/2017 6:23:37 PM" >
4. Failed : Xamarin.MTouch.RebuildTest_WithExtensions("debug","",True,System.String[])
debug
Expected: <empty>
But was: < "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory306/testServiceExtension.appex/testServiceExtension is modified, timestamp: 5/29/2017 6:24:22 PM", "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory306/testServiceExtension.appex/testServiceExtension.aotdata.armv7 is modified, timestamp: 5/29/2017 6:24:22 PM", "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory306/testServiceExtension.appex/testServiceExtension.dll.config is modified, timestamp: 5/29/2017 6:24:21 PM" >
5. Failed : Xamarin.MTouch.RebuildTest_WithExtensions("single-framework","",False,System.String[])
single-framework
Expected: <empty>
But was: < "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory310/testServiceExtension.appex/testServiceExtension is modified, timestamp: 5/29/2017 6:25:07 PM", "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-
The AVFoundation framework's headers used to be broken in the simulator SDK
([1], [2]) until watchOS 3.2 (Xcode 8.3) fixed it. This means it's now safe to
use AVFoundation.
Additionally set the initial SDK version where this framework was introduced
to 3.2 for simulator builds, which means that if customers try to use it (with
an old Xcode), they will get a nice-ish error:
> MTOUCH : error MT4134: Your application is using the 'AVFoundation' framework, which isn't included in the watchOS SDK you're using to build your app (this framework was introduced in watchOS 3.2, while you're building with the watchOS 3.1 SDK.) Please select a newer SDK in your app's watchOS Build options.
instead of an ugly:
> MTOUCH : error MT4109: Failed to compile the generated registrar code. Please file a bug report at http://bugzilla.xamarin.com
the error message is slightly incorrect (the problem is only with the
simulator SDK, not the device SDK), but this should happen very rarely (it
only occurs if all of the following are true: using AVFoundation + in a
simulator build * the static registrar manually selected), so IMHO a more
accurate error description isn't worth it.
https://bugzilla.xamarin.com/show_bug.cgi?id=56862
[1] 7149661251
[2] https://openradar.appspot.com/29131674
* Update to mono 2017-04 branch
* Patch from Zoltan to fix build error with CppSharp.CppParser.dll
* Include new linker files in Makefile, based on mareks commit
* [msbuild] Fix running bgen for Xamarin.Mac.
bgen must be executed with the system mono, not bmac-mobile-mono, and without
the MONO_PATH variable set.
* System.Data tests should act as if they are running on mobile profile
* Add --runtime=mobile to mono flags in Modern
* Move runtime launcher options up
* System.Data tests should use Mobile profile (mac fix)
* Bump 2017-04 to pick up AOT and assembly resolution fixes
* Build fixes for netstandard.dll and System.Drawing.Primitives.dll
The new handling went in with https://github.com/mono/mono/pull/4501.
I also noticed that WatchOS was missing a target for System.Drawing.Primitives.dll, so I added that.
* Add netstandard.dll to 2.1/Facades and System.Drawing.Primitives.dll to WatchOS
* Fix 2.1/Facades/netstandard.dll build
* Fix the netstandard targets
* Bump mono to latest 2017-04 commit
* [xharness] Fix adding defines to csproj by correctly detecting existing defines.
* Bump mono to latest 2017-04 commit
* [mtouch] Update csproj with new files.
* [mtouch] Improve reporting for MarkExceptions from the linker.
* Bump mono to latest 2017-04 commit
* Bump mono to pick up latest 2017-04 branch commit (Fixes#55436)
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=55436
* Add a missing Makefile dependency
* Chris Hamons patch to apply --runtime=mobile as necessary at AOT time
(It is currently being applied for some configurations at runtime only)
* Bump system mono
* Bump mono for assembly loader changes
* Bump system mono
* Update assemblies list as some where moved to facades
6ca5ec442bc38e4d9220
* Bump mono to latest 2017-04 commit
* Add another new facade
* Bump mono to tip of 2017-04.
* Bump mono to tip of 2017-04.
* [tests][mtouch] Adjust tests to cope with fewer assemblies being included in linked apps. Fixes#56307 and #56308.
System.dll is now completely linked away unless the app actually uses any
System.dll API.
This is the change that caused this to change: 4960d5d2a2
Previously the following types would always be kept by the linker:
```
$ monodis --typedef System.dll
Typedef Table
1: (null) (flist=1, mlist=1, flags=0x0, extends=0x0)
2: ObjCRuntime.INativeObject (flist=1, mlist=1, flags=0xa0, extends=0x0)
3: Mono.Net.CFObject (flist=1, mlist=2, flags=0x100000, extends=0x5)
4: Mono.Net.CFArray (flist=4, mlist=19, flags=0x100, extends=0xc)
5: Mono.Net.CFNumber (flist=5, mlist=32, flags=0x100100, extends=0xc)
6: Mono.Net.CFRange (flist=5, mlist=41, flags=0x100108, extends=0x25)
7: Mono.Net.CFString (flist=7, mlist=42, flags=0x100100, extends=0xc)
8: Mono.Net.CFData (flist=8, mlist=53, flags=0x100100, extends=0xc)
9: Mono.Net.CFDictionary (flist=8, mlist=63, flags=0x0, extends=0xc)
10: Mono.Net.CFMutableDictionary (flist=10, mlist=75, flags=0x100100, extends=0x24)
11: Mono.Net.CFUrl (flist=10, mlist=80, flags=0x100100, extends=0xc)
12: Mono.Net.CFRunLoop (flist=10, mlist=83, flags=0x100100, extends=0xc)
13: Mono.Net.CFBoolean (flist=10, mlist=94, flags=0x100, extends=0x5)
14: Mono.AppleTls.SecCertificate (flist=13, mlist=106, flags=0x100100, extends=0x5)
15: Mono.AppleTls.SecIdentity (flist=14, mlist=122, flags=0x100, extends=0x5)
16: Mono.AppleTls.SecIdentity/ImportOptions (flist=19, mlist=134, flags=0x100105, extends=0x5)
17: Mono.AppleTls.SecKey (flist=19, mlist=134, flags=0x100100, extends=0x5)
18: Mono.AppleTls.SecStatusCode (flist=21, mlist=141, flags=0x100, extends=0x69)
19: Mono.AppleTls.SecTrustResult (flist=395, mlist=141, flags=0x100, extends=0x69)
20: Mono.AppleTls.SecImportExport (flist=404, mlist=141, flags=0x100100, extends=0x5)
21: Mono.AppleTls.SecImportExport/<>c (flist=404, mlist=144, flags=0x102103, extends=0x5)
22: Mono.AppleTls.SecPolicy (flist=406, mlist=147, flags=0x100100, extends=0x5)
23: Mono.AppleTls.SecTrust (flist=407, mlist=154, flags=0x100100, extends=0x5)
24: System.Security.Cryptography.OidGroup (flist=408, mlist=174, flags=0x101, extends=0x69)
25: System.Security.Cryptography.Oid (flist=420, mlist=174, flags=0x100101, extends=0x5)
26: System.Security.Cryptography.CAPI (flist=423, mlist=176, flags=0x100180, extends=0x5)
27: System.Security.Cryptography.AsnEncodedData (flist=423, mlist=178, flags=0x100101, extends=0x5)
28: System.Security.Cryptography.X509Certificates.X509Utils (flist=424, mlist=179, flags=0x100100, extends=0x5)
29: System.Security.Cryptography.X509Certificates.PublicKey (flist=424, mlist=181, flags=0x100101, extends=0x5)
30: System.Security.Cryptography.X509Certificates.X509Certificate2 (flist=429, mlist=188, flags=0x102101, extends=0x51)
31: System.Security.Cryptography.X509Certificates.X509Certificate2Impl (flist=431, mlist=204, flags=0x100080, extends=0x55)
32: System.Security.Cryptography.X509Certificates.X509CertificateCollection (flist=431, mlist=209, flags=0x102101, extends=0x6d)
33: System.Security.Cryptography.X509Certificates.X509CertificateCollection/X509CertificateEnumerator (flist=431, mlist=212, flags=0x100102, extends=0x5)
34: System.Security.Cryptography.X509Certificates.X509Helper2 (flist=432, mlist=217, flags=0x100180, extends=0x5)
35: <PrivateImplementationDetails> (flist=432, mlist=218, flags=0x100, extends=0x5)
36: <PrivateImplementationDetails>/__StaticArrayInitTypeSize=9 (flist=433, mlist=219, flags=0x113, extends=0x25)
```
Some of the above types from System.dll implemented ObjCRuntime.INativeObject
(from System.dll), which our linker detected as implementing
ObjCRuntime.INativeObject (from Xamarin.iOS.dll), so these types were treated
as custom NSObject subclasses, and the MarkNSObjects linker step would mark
them (which would in turn cause all the other types in the list to be marked).
With that change, these types now implement ObjCRuntimeInternal.INativeObject,
and the linker does not treat them as custom NSObject subclasses anymore.
I think the new behavior is correct: these types do not actually inherit from
the real NSObject/INativeObject, so the linker should not treat them as such.
This may run into different bugs because the linker might now remove more
stuff than before, but that would be a different issue.
This means that the fix is to modify these tests accordingly.
https://bugzilla.xamarin.com/show_bug.cgi?id=56307https://bugzilla.xamarin.com/show_bug.cgi?id=56308
* Bump mono to latest.
* Fix merge conflict that was missed
* [mtouch] Renumber new error which clashes with an existing error number in master.
Rolf Bjarne Kvinge
Chris Hamons
Sebastien Pouliot
Timothy Risi
Manuel de la Pena
Bernhard Urban
Sebastien Pouliot
Manuel de la Pena
Ludovic Henry
Alex Soto
Vincent Dondain
Andy Martin
Marius Ungureanu
Andi McClure