* [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
* [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
* [tests][mtouch] Convert MT4162 to new syntax.
This also means adding support for custom usings in test code, and adding
support for asserting filename/linenumber with error patterns, and custom
pattern syntax.
* [tests][mtouch] Add test case for bug #59617.
This amounts to running the MT4162 test with the linker enabled.
https://bugzilla.xamarin.com/show_bug.cgi?id=59617
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
* [mtouch/mmp] Downgrade MT0123 to a verbose log statement instead.
It's unlikely to be useful for normal people who've just set LANG for whatever
unrelated reason.
If it's needed to diagnose failures, it'll still show up in verbose logs.
* [docs] Remove MT0123, it's no longer being used, and we never released a version that used it either.
* [tests][mtouch] Update tests according to code changes (MT0123 removal).
* [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
Fix collecting required internal symbols which aren't in the objc_msgSend
family by not bailing out early for a function which isn't in the objc_msgSend
family.
Also add a test.
* [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.
When we process P/Invokes to add support for exception marshaling, we may
change P/Invokes to be __Internal. This means that we need to move the check
for __Internal P/Invokes to after processing P/Invokes for exception
marshaling.
https://bugzilla.xamarin.com/show_bug.cgi?id=57833
Previously the assumption was that if an assembly not using dlsym references a
native symbol, it's not a required symbol. This is true as far as the native
linker goes: the native linker will see that the native symbol is referenced
by the AOT-compiled code, and it won't be removed.
However, we use also this exact logic to create the list of functions we ask
the native strip command to preserve, and in this case we need to include all
symbols needed in all assemblies that looks up native functions using dlsym.
https://bugzilla.xamarin.com/show_bug.cgi?id=57826
Fixes:
1. Failed : Xamarin.MTouch.MT0091(tvOS,"tvOS")
The error 'MT0091: This version of Xamarin.iOS requires the tvOS 11.0 SDK (shipped with Xcode 9.0). Either upgrade Xcode to get the required header files or set the managed linker behaviour to Link Framework SDKs Only (to try to avoid the new APIs).' was not found in the output:
Message #1 did not match:
actual: 'This version of Xamarin.iOS requires the tvOS 11.0 SDK (shipped with Xcode 9). Either upgrade Xcode to get the required header files or set the managed linker behaviour to Link Framework SDKs Only (to try to avoid the new APIs).'
expected: 'This version of Xamarin.iOS requires the tvOS 11.0 SDK (shipped with Xcode 9.0). Either upgrade Xcode to get the required header files or set the managed linker behaviour to Link Framework SDKs Only (to try to avoid the new APIs).'
2. Failed : Xamarin.MTouch.MT0091(iOS,"iOS")
The error 'MT0091: This version of Xamarin.iOS requires the iOS 11.0 SDK (shipped with Xcode 9.0). Either upgrade Xcode to get the required header files or set the managed linker behaviour to Link Framework SDKs Only (to try to avoid the new APIs).' was not found in the output:
Message #1 did not match:
actual: 'This version of Xamarin.iOS requires the iOS 11.0 SDK (shipped with Xcode 9). Either upgrade Xcode to get the required header files or set the managed linker behaviour to Link Framework SDKs Only (to try to avoid the new APIs).'
expected: 'This version of Xamarin.iOS requires the iOS 11.0 SDK (shipped with Xcode 9.0). Either upgrade Xcode to get the required header files or set the managed linker behaviour to Link Framework SDKs Only (to try to avoid the new APIs).'
3. Failed : Xamarin.Registrar.NoWarnings
no warnings
Expected: not String matching "warning:"
But was: "/Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory298/mtouch-test-cache/registrar.m:32468:17: warning: method 'paymentAuthorizationViewController:didAuthorizePayment:handler:' in protocol 'PKPaymentAuthorizationViewControllerDelegate' not implemented [-Wprotocol]"
https://bugzilla.xamarin.com/show_bug.cgi?id=57601
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
* [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
* 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.
* [mtouch] Allow code sharing assemblies from multiple locations if they're identical. Fixes#56498.
We disallow code sharing when the same assembly (based on name) is referenced
from multiple paths, but poke a hole in this logic by allowing the same
assembly from multiple paths when those assemblies are 100% identical, since
that should be 100% safe.
https://bugzilla.xamarin.com/show_bug.cgi?id=56498
* [tests] Comment out assert that asserts due to another bug.
If both an extension and the container app (or multiple extensions) reference
the same binding assembly for a framework, then we'd error out with an
internal error when trying to copy the framework from both locations to the
container app.
So instead detect when we're trying to copy multiple identical (by comparing
the on-disk contents) frameworks, and only copy one of them.
We'll still show an error if the frameworks are different, but now a nice
MT1035 error with a proper error description instead of an internal error.
https://bugzilla.xamarin.com/show_bug.cgi?id=56635
* [mmp/mtouch/ObjCRuntime] Calculate the path to the runtime-options.plist using NSBundle's ResourcePath.
The anatomy of apps and frameworks differ between iOS and macOS:
* iOS: we put runtime-options.plist in the root directory of the app.
* macOS:
* for apps we put runtime-options in foo.app/Contents/Resources
* for frameworks we put runtime-options in foo.framework/Versions/Current/A/Resources
Luckily NSBundle's ResourcePath property returns exactly this path, so change
our logic to use this property.
Also calculate the NSBundle using an exported type we know we have (using the
main bundle won't work when we're a framework).
* [tests] Add mmp/mtouch tests to verify the default HttpClientHandler according to build arguments.
* [ObjCRuntime] Use a custom class for finding the bundle.
Use a self-defined custom class to find the bundle where our resources are.
Using the internal NSObject.NSObject_Disposer class doesn't work when this
file (RuntimeOptions.cs) is compiled into System.Net.Http.dll.
It does not make sense to support incremental builds for the simulator (since
no AOT compilation is done), it just makes the test matrix more complicated.
So simplify things by removing support for incremental builds.
We also ignore any (other) --assembly-build-target arguments, because building
to frameworks doesn't make sense either in the simulator.
https://bugzilla.xamarin.com/show_bug.cgi?id=55712
This dramatically decreases the size of watchOS apps built for debug when
using frameworks, because it ends up removing all the bitcode from
Mono.framework.
https://bugzilla.xamarin.com/show_bug.cgi?id=55256
Of particular importance is if we're building for LLVM or not: this fixes a
bug where we wouldn't pass --llvm to the AOT compiler when compiling
assemblies to frameworks (which we do when sharing code).
https://bugzilla.xamarin.com/show_bug.cgi?id=55555
* Remove the MT0008 test, since the error will never be shown again.
* Check non-existent root assemblies and report MT0018 instead of MT0007 if
they look like command-line arguments.
* Collect all MT0018/MT0007 errors before reporting any of them.
We want to copy the aot data for both the 32-bit and the 64-bit versions of an
assembly even if the 32-bit and 64-bit versions of the assembly are identical.
https://bugzilla.xamarin.com/show_bug.cgi?id=54499
Sebastien Pouliot
Manuel de la Pena
Chris Hamons
Rolf Bjarne Kvinge
Bernhard Urban
Sebastien Pouliot
Timothy Risi
Andi McClure
Marek Safar