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.
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
Some Quote implementations quoted backslashes, some didn't. When selecting a
common implementation, one of the implementations that didn't quote
backslashes won, and the rest were forgotten. Almost. Except for the MT0106
test, which started failing, thus exposing the winner's deficiencies.
So dethrone the implementation that won and reinstante the importance of the
backslash.
https://bugzilla.xamarin.com/show_bug.cgi?id=57768
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
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.
* [registrar] Add support for specifying that a protocol changed informal status in a certain SDK. Fixes#43780
Add support for specifying that an informal protocol became a formal protocol
(or the reverse) in a certain SDK version, so that the static registrar can
generate the correct code based on the SDK being built with.
This also fixes a series of compiler warnings when using the static registrar:
In file included from Xamarin.Mac.registrar.full.i386.m:1:
./Xamarin.Mac.registrar.full.i386.h:374:11: warning: duplicate protocol definition of 'CALayerDelegate' is ignored
@protocol CALayerDelegate
^
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/QuartzCore.framework/Headers/CALayer.h:798:11: note: previous definition is here
@protocol CALayerDelegate <NSObject>
^
In file included from Xamarin.Mac.registrar.full.i386.m:1:
./Xamarin.Mac.registrar.full.i386.h:824:11: warning: duplicate protocol definition of 'WebDownloadDelegate' is ignored
@protocol WebDownloadDelegate
^
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/WebKit.framework/Headers/WebDownload.h:60:11: note: previous definition is here
@protocol WebDownloadDelegate <NSURLDownloadDelegate>
^
In file included from Xamarin.Mac.registrar.full.i386.m:1:
./Xamarin.Mac.registrar.full.i386.h:851:11: warning: duplicate protocol definition of 'WebFrameLoadDelegate' is ignored
@protocol WebFrameLoadDelegate
^
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/WebKit.framework/Headers/WebFrameLoadDelegate.h:51:11: note: previous definition is here
@protocol WebFrameLoadDelegate <NSObject>
^
In file included from Xamarin.Mac.registrar.full.i386.m:1:
./Xamarin.Mac.registrar.full.i386.h:866:11: warning: duplicate protocol definition of 'WebPolicyDelegate' is ignored
@protocol WebPolicyDelegate
^
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/WebKit.framework/Headers/WebPolicyDelegate.h:138:11: note: previous definition is here
@protocol WebPolicyDelegate <NSObject>
^
In file included from Xamarin.Mac.registrar.full.i386.m:1:
./Xamarin.Mac.registrar.full.i386.h:869:11: warning: duplicate protocol definition of 'WebResourceLoadDelegate' is ignored
@protocol WebResourceLoadDelegate
^
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/WebKit.framework/Headers/WebResourceLoadDelegate.h:46:11: note: previous definition is here
@protocol WebResourceLoadDelegate <NSObject>
^
In file included from Xamarin.Mac.registrar.full.i386.m:1:
./Xamarin.Mac.registrar.full.i386.h:872:11: warning: duplicate protocol definition of 'WebUIDelegate' is ignored
@protocol WebUIDelegate
^
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/WebKit.framework/Headers/WebUIDelegate.h:153:11: note: previous definition is here
@protocol WebUIDelegate <NSObject>
^
https://bugzilla.xamarin.com/show_bug.cgi?id=43780
* [registrar] Use a string to specify when a protocol went from informal to formal.
Use a string to specify when a protocol went from informal to formal, and
don't support the reverse condition (going from formal to informal), since
it's currently not needed and makes the code more complicated and harder to
understand.
Also add an mtouch test, and update an existing mmp test to be more restrictive.
* [registrar] Rename from 'InformalUntil' to 'FormalSince'.
It just sounds better.
* [generator] Keep [NotImplemented] info so it is usable in 3rd party bindings. Fixes bug 52664
https://bugzilla.xamarin.com/show_bug.cgi?id=52664
Currently we do not keep the [NotImplemented](0) information and the
generator gets a little confused because it will not find an Export
inside the getters/setters of properties and there is no way to tell
if this was intentional or not. We now keep the [NotImplemented]
and also add some null checks in the generator where needed.
Reenabled tests disabled in 9f036b218a
[0]: https://developer.xamarin.com/guides/cross-platform/macios/binding/objective-c-libraries/#Objective-C_Mutable_Pattern_and_Properties
* [generator] Implement feedback
* Added quote method
* Teach linker about NotImplementedAttribute
* [generator] Improve Quote method
* [generator] Fix quote now for realsssss
This avoids the following compiler warning:
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/OpenGL.framework/Headers/gl.h:5:2: warning: gl.h and gl3.h are both included. Compiler will not invoke errors if using removed OpenGL functionality. [-W#warnings]
I found the magic symbol by looking at the headers.
* [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.
* [mtouch] Don't look for assembly references in attributes in assemblies we ship. Partially fixes#49087.
Don't look for assembly references in attributes in assemblies we ship,
because it takes a significant amount of time to do this, and we can
precompute the fact that there aren't any such assembly references.
Additionally add a test to ensure we catch any changes to this assumption.
For a simple test app this makes rebuilding (without any changes) go from
~1.1s to ~0.4s.
https://bugzilla.xamarin.com/show_bug.cgi?id=49087
* [tests] Simplify tests to not use [TestCaseSource].
Using [TestCaseSource] is nice when running from the IDE, since it shows all
test cases in the test tree.
Unfortunately it causes the console runner to freak out [1], because the method
that lists all the test cases calls Configuration's cctor, which calls
TestContext.CurrentContext.TestDirectory, which is apparently not safe this
early in the test run.
[1] I think 'freak out' is the appropriate term for this behavior, which has
absolutely no direct nor obvious connection to the cause of the problem:
System.Runtime.Remoting.RemotingException: Cannot create channel sink to connect to URL 93a78115_c0da_4b6a_9661_9f9b9d9fb935/6669afd6_4.rem. An appropriate channel has probably not been registered.
Server stack trace:
at System.Runtime.Remoting.RemotingServices.GetClientChannelSinkChain (System.String url, System.Object channelData, System.String& objectUri) [0x00019] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Remoting.RemotingServices.GetOrCreateClientIdentity (System.Runtime.Remoting.ObjRef objRef, System.Type proxyType, System.Object& clientProxy) [0x0001d] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Remoting.RemotingServices.GetRemoteObject (System.Runtime.Remoting.ObjRef objRef, System.Type proxyType) [0x00000] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Remoting.RemotingServices.GetProxyForRemoteObject (System.Runtime.Remoting.ObjRef objref, System.Type classToProxy) [0x0001b] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Remoting.RemotingServices.Unmarshal (System.Runtime.Remoting.ObjRef objectRef, System.Boolean fRefine) [0x0007a] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Remoting.RemotingServices.Unmarshal (System.Runtime.Remoting.ObjRef objectRef) [0x00000] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Remoting.ObjRef.GetRealObject (System.Runtime.Serialization.StreamingContext context) [0x0000f] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Serialization.ObjectManager.ResolveObjectReference (System.Runtime.Serialization.ObjectHolder holder) [0x00010] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Serialization.ObjectManager.DoFixups () [0x0007f] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize (System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Runtime.Serialization.Formatters.Binary.__BinaryParser serParser, System.Boolean fCheck, System.Boolean isCrossAppDomain, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x00077] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Boolean fCheck, System.Boolean isCrossAppDomain, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x000a2] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Boolean fCheck, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x00000] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.DeserializeMethodResponse (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x00000] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage (System.Runtime.Remoting.Messaging.IMessage msg) [0x00083] in <270c90abbc234cde9d33eb198a97cf71>:0
Fixes this compiler warning:
/work/maccore/master/xamarin-macios/tools/common/DerivedLinkContext.cs(12,28): warning CS0649: Field 'DerivedLinkContext.StaticRegistrar' is never assigned to, and will always have its default value null
and makes the mmp code closer to mtouch.
Make sure to instantiate an Assembly instance for every assembly loaded using
the cached list of assemblies.
Fixes the following test failures:
1. Xamarin.MTouch.RebuildTest_WithExtensions("single","",False,System.String[]) : second build
Expected: 0
But was: 1
2. Xamarin.MTouch.RebuildTest_WithExtensions("dual","armv7,arm64",False,System.String[]) : second build
Expected: 0
But was: 1
3. Xamarin.MTouch.RebuildTest_WithExtensions("llvm","armv7+llvm",False,System.String[]) : second build
Expected: 0
But was: 1
4. Xamarin.MTouch.RebuildTest_WithExtensions("debug","",True,System.String[]) : second build
Expected: 0
But was: 1
5. Xamarin.MTouch.RebuildTest_WithExtensions("single-framework","",False,System.String[]) : second build
Expected: 0
But was: 1
* [mtouch] Cache the list of assemblies we computed. Partially fixes#49087.
Computing the list of assemblies can be expensive, so cache it and re-use the
cached list if we can.
https://bugzilla.xamarin.com/show_bug.cgi?id=49087
* [mtouch] Create directory before trying to create files to it.
The generated registrar code must be built with -DDYNAMIC_MONO_RUNTIME so that
it references our local mono functions which do a dynamic function lookup.
This fixes an issue where release builds that don't embed mono fails to link,
because there are numerous unresolved externals pointing to mono symbols.
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
[registrar] Support 'out' parameters from NULL pointers. Fixes#54919.
Native code doesn't have the 'out' and 'ref' distinction C# has, and passes
NULL around left and right.
So make sure the generated code from the static registrar doesn't write to such NULLs.
https://bugzilla.xamarin.com/show_bug.cgi?id=54919
This XM-only RemoveSelectors works on FieldDefinition but in some cases,
e.g. inside a generic types, it's FieldReference that are encoded. This
meant the static constructor was not re-written correctly and would throw
a TargetInvocationException (since the fields were removed correctly)
https://bugzilla.xamarin.com/show_bug.cgi?id=55693
`csc` without `/optimize` generates different IL, including additional
and not required load and store instructions. We previously ignored them
but that could leave the stack unbalanced leading to runtime exceptions.
We are now nop'ing the extraneous instructions (same as the rest of the
unneeded branch code)
This fixes#53872 [1] and also the known parts of #56209 (the other parts
are still NEEDINFO and could, possibly, be unrelated).
[1] https://bugzilla.xamarin.com/show_bug.cgi?id=53872
[2] https://bugzilla.xamarin.com/show_bug.cgi?id=56209#c2
Replace https://github.com/xamarin/xamarin-macios/pull/1973 expect that
the test parts are still needed.
* Add XM SDK + LinkSkip test
* [macos] Add platform linking support to msbuild
* [macos] Add full SDK test
* [macios] Diable classic from using linkplatform
- Extended test infrastructure change to allow classic projects that include bundling
- Setting linkplatform in MonoBundlingExtraArgs since we don't even read project setting LinkMode - Platform for classic
- Actually enable hybrid AOT by adding argument in right location
- Hybrid AOT and stripping does not play well currently with partial AOT
- Fix AOT makefile to work with nuget nunit
- https://bugzilla.xamarin.com/show_bug.cgi?id=55041
This is because the generated output from the static registrar depends on the
managed exception marshaling mode, and the partial static registrar executes
with the default managed exception marshaling mode.
https://bugzilla.xamarin.com/show_bug.cgi?id=55870
* [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.
Rolf Bjarne Kvinge
Sebastien Pouliot
Timothy Risi
Andy Martin
Marius Ungureanu
Chris Hamons
Andi McClure
Alex Soto