We cannot use generics in native signatures but, with some care (and
generator work), we can still expose nullable on our public delegate API.
AUImplementorStringFromValueCallback is presently the only case of such
an API.
reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=42699
Apple has both an Empty and Null constants. Our implementation is largely
done in managed code and, for historical reasons [1], match System.Drawing
behaviour. Still the constant is useful for other (e.g. 3rd party) APIs.
Also add CFRect.Infinite for the missing CGRectInfinite symbol.
[1] In the original classic we only provided RectangleF not CGRect
references:
* https://bugzilla.xamarin.com/show_bug.cgi?id=43628
* xtro
common.unclassified:!missing-field! CGRectNull not bound
common.unclassified:!missing-field! CGRectInfinite not bound
* Move NSTouch ctor to code-behind and obsolete
* Remove XAMCORE_4_0 check for NSTouch DisableDefaultCtor
* Add NSTouch.cs to frameworks.sources
* Skip NSSpellCheckerCanidates in typo test
* [tests][generator] Port XI/Classic tests to XI/Unified.
* [tests][generator] Comment out code triggering previously unknown bugs.
These tests makes the generator fail:
error BI0000: 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 Generator.GetSetterExportAttribute (System.Reflection.PropertyInfo pinfo) [0x0002e] in /work/maccore/master/xamarin-macios/src/generator.cs:1981
at Generator.Go () [0x007e3] in /work/maccore/master/xamarin-macios/src/generator.cs:2162
at BindingTouch.Main2 (System.String[] args) [0x010b2] in /work/maccore/master/xamarin-macios/src/btouch.cs:435
at BindingTouch.Main (System.String[] args) [0x0001d] in /work/maccore/master/xamarin-macios/src/btouch.cs:77
at System.Environment.get_StackTrace () [0x00000] in /work/maccore/master/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/src/mono/mcs/class/corlib/System/Environment.cs:321
at ErrorHelper.ShowInternal (System.Exception e) [0x000dc] in /work/maccore/master/xamarin-macios/src/error.cs:200
at ErrorHelper.Show (System.Exception e) [0x00027] in /work/maccore/master/xamarin-macios/src/error.cs:151
at BindingTouch.Main (System.String[] args) [0x0002b] in /work/maccore/master/xamarin-macios/src/btouch.cs:79
This has been filed as https://bugzilla.xamarin.com/show_bug.cgi?id=52664.
* [tests][generator] Comment out code triggering previously unknown bugs.
This has been filed as https://bugzilla.xamarin.com/show_bug.cgi?id=52665.
Fixes this warning:
Makefile:163: warning: overriding commands for target `virtualwrap'
Makefile:40: warning: ignoring old commands for target `virtualwrap'
The `CFStreamEventType` enum is based on `NSUInteger`. The native delegate
CallbackDelegate was using it directly and that made it incorrect on 32
bits platforms.
We have introspection tests to check enums on p/invoke, but it seems they
don't cover native delegates - decorated with [MonoNativeFunctionWrapper]
That's to be added in a different PR.
references:
https://bugzilla.xamarin.com/show_bug.cgi?id=52279
* [tests][intro] Validate signatures of delegates decorated with [MonoNativeFunctionWrapper]
Deleting the directory when the test completes just makes it harder to copy-
paste the failing command.
Any directories created by Cache.CreateTemporaryDirectory will automatically
be deleted at the next test run, so this won't use up disk space.
* [generator] Have WrapAttribute generate virtual members
WrapAttribute now has a boolean optional parameter named isVirtual,
this instructs the generator to add the virtual keyword to generated
members.
This is useful when fixing breaking changes so we can keep the wrong
signature generated instead of having manual code files.
* [docs] Add docs about virtual to WrapAttribute
Change how the registrar calls mtouch a bit, so that we don't use API that
throws an exception with the entire output in the exception message.
The problem is that if the process has a lot of output, XS slows down to a
crawl when showing the exception message in the test result pad.
Instead print the output to the terminal.
* [tests/link sdk] Remove defines that are set by default.
And these defines varies by platform, which means they're not correct for tvOS/watchOS.
* [tests/link sdk] Fix watchOS version check.
Sometimes, when the stars align, fastsim can build an app in less than a
second.
Coupled with the fact that HFS+'s filestamp resolution is 1 second, we can't
assert that filestamps change without making sure enough time passes by.
So sleep for a second.
https://bugzilla.xamarin.com/show_bug.cgi?id=47696
* [XM] Seperate parsing from compilation in AOT code
- Parsing command line options was too entangled with actually compiling
- Refactor test code to centralize Compile, reducing some complexity of tests
- Groundwork for hybrid vs non-hybrid AOT work
* Add hybrid/standard AOT support
* Add xammac_tests to makefile/jenkins
* Add flag to force AOT
* Disable MonoTouchFixtures.Contacts.ContactStoreTest.GetUnifiedContacts on XM due to prompts on Jenkins
We disabled fastdev for tvOS/watchOS projects with binding projects in
bac02538, and that broke the FastDev_LinkWithTest:
Errors and Failures:
1) Test Failure : Xamarin.MTouch.FastDev_LinkWithTest(TVOS)
Binding symbol not in executable
Expected: no item String ending with " T _theUltimateAnswer"
But was: < ... >
So adjust the test to match the new behavior.
Resource files for mac should be copied to the app bundle
* Move the Satellite code used by mac to tools/common/Assembly.cs
* Add EmbeddedResources test to xammac_tests
Fix NSOpenGLPixelFormat ConvertToAttributes
* Add OpenGLProfile to list of NSOpenGLPixelFormatAttributes that require a value. Check for 0 terminating the array
* Use InitializeHandle instead of 'Handle = '
* Add tests
The latest Sierra had a few surprises:
* CITextFeature is now 64bits only;
* The MediaPlayer framework is now 64bits only [1]
Both made the classic tests fails for XM.
[1] https://bugzilla.xamarin.com/show_bug.cgi?id=52065
* [generator] Add BindAs support for NSValue and NSNumber
https://trello.com/c/RYCPEnkh
The intent of BindAs attribute is to have a binding definition as
[return: BindAs (typeof (bool?))]
[Export ("boolMethod:")]
NSNumber BoolMethod (int arg1);
and our generator outputs
[Export ("boolMethod:")]
public virtual global::System.Nullable<bool> BoolMethod (int arg1) { ... }
So we internally do the NSNumber <-> bool conversion, this also
applies to properties, parameters and methods.
* [generator] Fix a small formating issue
* [tests] Add BindAsAttribute generator tests
* [generator] Implement @spouliot's feedback
* [tests] Add BI1048 and BI1049 error tests for [BindAs]
* [generator] Implement Rolf's suggestion to avoid almost all string comparisons in [BindAs] for types
* [generator] Add BindAs support for smart enums and arrays with tests
* [generator] Some code clean up and implementation of PR feedback
* [generator] Add Protocol|Model checks and tests also a NRE check in NSArray creator
BindAs attribute cannot be used in Protocol|Model interfaces
* [generator] Add NSNumber <-> Enum support
* [docs] add BindAs documentation
* [docs] Implement documentation feedback for BindAs
Use @rpath instead of @executable_path in dylibs, since it allows us to be
more flexible when placing dylibs in the app.
In particular with this change it's trivial to put libmonosgen-2.0.dylib in
the container app, and reference it from extensions.
HFS timestamp resolution is 1 second, which means that we can't distinguish
files modified again within 1 second. This means that this test will fail more
often the faster we make mtouch, so add a forced sleep to make sure we don't
do things faster than the file system can keep track of.
Performance tests
-----------------
This is for a new watchOS extension project, built for release.
* The default (currently -O2) optimizations: 41s ( baseline ) 30.027.060 bytes ( baseline )
* All optimizations disabled (`--llvm-opt=all=`): 17s (-24s = -59%) 32.978.312 bytes (+2.951.252 = +10%)
* Optimized for size (`--llvm-opt=all=-Os`): 36s ( -5s = -12%) 28.617.408 bytes (-1.409.652 = -5%)
* Optimized for more size (`--llvm-opt=all=-Oz`): 35s ( -6s = -15%) 28.601.016 bytes (-1.426.044 = -5%)
* Optimized slightly (`--llvm-opt=all=-O1`): 35s ( -6s = -15%) 28.666.556 bytes (-1.360.504 = -5%)
* Optimized a lot (`--llvm-opt=all=-O3`): 41s ( 0s = 0%) 30.403.996 bytes (+ 376.936 = +1%)
Conclusions
-----------
* The fastest build by far (less than twice as fast) is if optimizations are
disabled, but this adds a 10% size penalty (~3 MB in this test case),
compared to the baseline, and 15% size penalty (4.3 MB) compared to -Oz.
* -Oz seems to have the best overall results: at least as fast as any other
optimized build, and the smallest app as well.
Caveats
-------
Some optimizations might not work the AOT compiled code. The resulting
binaries have not been tested.
Event sequence:
* mtouch is executed with the linker disabled.
* The linker pipeline copies all input assemblies (since the linker is
disabled the assemblies don't change) into the PreBuild directory. This will
keep the original timestamps of the input assemblies.
* mtouch is executed again, when none of the input assemblies changed.
* The linker pipeline will re-execute, because it will see that at least one
of the input assemblies (at least the .exe) is newer than at least one of
the assemblies in the PreBuild directory (usually a framework assembly,
because those have the original timestamp from their install location).
Fix:
Touch all the assemblies in the PreBuild directory after the linker pipeline
executes the first time. This way the second time mtouch is executed, it will
find that all assemblies in the PreBuild directory have timestamps later than
all the input assemblies, so it will load the cached linked assemblies,
instead of re-executing the linker pipeline.
* [xharness] Show test xml files in the html report.
* [xharness] Force links to xml files to show up in a new top-level window.
Jenkins shows the html report in an iframe, and links will load in that
iframe. This means that the browser renders the contents of the link as if it
was html, and rendering xml as html results in a blank page.
So set the target attribute on links to xml files, so that those xml files
open as top-level pages, and then the browser will rendering the xml like xml.
The native linker treats object files (.o) and static libraries (.a files,
which are archives of .o files) differently.
The native linker will always include object files into the executable:
$ echo "void xxx () {}" > foo.m
$ clang -c foo.m -o foo.o -arch x86_64
$ ld foo.o -dylib -o foo.dylib -macosx_version_min 10.12 -arch x86_64
$ nm foo.dylib
0000000000000fe0 T _xxx
However, if the object file is inside a static library:
$ echo "void xxx () {}" > foo.m
$ clang -c foo.m -o foo.o -arch x86_64
$ ar cru foo.a foo.o
$ ld foo.a -dylib -o foo.dylib -macosx_version_min 10.12 -arch x86_64
$ nm foo.dylib
<no output>
This means that our testing library (libtest.a) which is a fat library of
_object files_, do not show the problems reported in bug #51548.
So:
a) I've fixed the creation of libtest.a to be a fat library of _static
libraries_. This causes the `FastDev_LinkWithTest` test to fail exactly
like in bug #51548.
b) I've made mtouch pass `-u <native symbol>` to the native linker, for every
native symbol referenced in a managed assembly, when creating a dylib.
Amazingly this seems to work fine even with symbols to Objective-C classes
(`_OBJC_CLASS_$_<class name>`).
c) This also required adding support for collecting the Objective-C names of
all managed types registered with Objective-C to the linker. The
information is already available in the static registrar, but that would
require us to make sure the static registrar is executed before compiling
dylibs, which means those two tasks won't be able to run in parallel (also
there's no guarantee we'll even run the static registrar).
https://bugzilla.xamarin.com/show_bug.cgi?id=51548
TL&DR: This is *how* it should be done and tested, it's not complete
(single, simple case) nor the most interesting case ;-)
The trick is to make sure each case is covered by tests so a mono
_bump_ won't give us a BCL that does not conform to what the linker
expect.
What's the impact ?
1. There is the expected reduction of metadata in mscorlib. Since both
methods don't call other API there's no indirect effect (removal).
--- before 2017-01-15 11:12:44.000000000 -0500
+++ after 2017-01-15 11:12:56.000000000 -0500
@@ -13166,9 +13166,6 @@
System.Void System.Security.SecurityException::.ctor(System.Runtime.Serialization.SerializationInfo,System.Runtime.Serialization.StreamingContext)
System.Void System.Security.SecurityException::.ctor(System.String)
System.Void System.Security.SecurityException::GetObjectData(System.Runtime.Serialization.SerializationInfo,System.Runtime.Serialization.StreamingContext)
-System.Boolean System.Security.SecurityManager::CheckElevatedPermissions()
-System.Security.SecurityManager
-System.Void System.Security.SecurityManager::EnsureElevatedPermissions()
System.Security.SecurityRulesAttribute
System.Security.SecurityRuleSet System.Security.SecurityRulesAttribute::m_ruleSet
System.Void System.Security.SecurityRulesAttribute::.ctor(System.Security.SecurityRuleSet)
2. There is no visible size change (even with #1) in mscorlib.dll due to
padding (compiler /filealign)
mscorlib.dll 793,600 793,600 0 0.00 %
3. there's a *very* small reduction of mscorlib.*.aotdata size
mscorlib.armv7.aotdata 717,264 717,216 -48 -0.01 %
mscorlib.arm64.aotdata 712,840 712,704 -136 -0.02 %
AOT data *.aotdata 6,460,064 6,459,880 -184 0.00 %
4. there's no change in executable size - normal as the AOT compiler has
_likely_ already doing the same optimization (before this commit)
Executable 29,270,272 29,270,272 0 0.00 %
Full comparison: https://gist.github.com/spouliot/0464c8fa3a92b6486dfd90595d9eb718