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
a. System.Net.Http.Primitives.dll is user code *and* contains type
forwarders (it's like a facade) to another facade assembly,
System.Net.Primitives.dll, that ships with the SDK;
b. The former, System.Net.Http.Primitives.dll, is not processed by
the linker, e.g. no code is removed and the assembly cannot be deleted.
However we save back (as much as we can [1]) the result of any type
being resolved;
c. It also means the later, System.Net.Primitives.dll, is fully linked
and (in many cases) can be removed from the final application (as it's
mostly forwarders).
d. This means the final, re-saved, System.Net.Http.Primitives.dll binary
could point to non-existing metadata, i.e. the removed
System.Net.Primitives.dll, because of [1].
Because we resolve (and save) the forwarders *and* because we do not
allow code downloads or generation (Apple restriction) it is possible to
remove the forwarders, which will fix the issue for XI.
[1] The scope of exported types cannot be updated
abb4e902da/Mono.Cecil/ExportedType.cs (L41)
There is also a enhancement bug, #11165, about this but it predated our
PCL support and the resolve-n-save that we now do for forwarders. This
is now _fully_ fixed.
References:
* https://bugzilla.xamarin.com/show_bug.cgi?id=11165 (enhancement)
* https://bugzilla.xamarin.com/show_bug.cgi?id=51805
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
Most projects building to bitcode (any kind of bitcode, this includes the
marker-only version as well), will fail to link when linking with third-party
libraries and incremental builds are enabled.
So automatically disable incremental builds when we detect this scenario.
This is only a workaround until we can make this scenario build correctly.
https://bugzilla.xamarin.com/show_bug.cgi?id=51710
* [Debugger] Ensure that we use the correct paths in the mono mdb files to be able to step into the mono code.
Fixes bug 51530.
* Make the mdb paths to be correct in other platforms.
* Ensure mdb paths are also correct in XM.
* [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.
According to Vlad it's not necessary to set MONO_GC_PARAMS during AOT-
compilation, since all MONO_GC_PARAMS options can be changed at runtime:
Rolf Kvinge [16:35] @vlad.brezae is this true for all the different options MONO_GC_PARAMS take: https://github.com/xamarin/xamarin-macios/pull/1546#discussion_r97318092?
Rolf Kvinge [16:36] I remember this: https://bugzilla.xamarin.com/show_bug.cgi?id=35414#c14
Rofl Kvinge [16:36] which apparently you changed here, so that it can be changed at runtime: https://bugzilla.xamarin.com/show_bug.cgi?id=35414#c27
Rolf Kvinge [16:36] but I don't know if this is true for all the options you can pass using MONO_GC_PARAMS
Vlad Brezae [16:41] yes, it should be true for all of them, that was a bug
Rolf Kvinge [16:41] ok, that's great news 😄
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.
Current mono master is versioned as `409001455` in it's updateinfo
which (technically) violates the format. Rewrite the parser to take
an arbitrary number of digits in the final slot instead of assuming
it's always going to be 3.
Now you can provision mono/master:
```
$ cat /Library/Frameworks/Mono.framework/Home/updateinfo
964ebddd-1ffe-47e7-8128-5ce17ffffb05 409001455
$ cat /Library/Frameworks/Mono.framework/Home/updateinfo | cut -d' ' -f2 | cut -c6- | awk '{print(int($0))}'
1455
```
This can happen when a parameter of the method being [Async]-ified has
the same name as one of the delegate parameter.
E.g.
* Binding code
```
delegate void MTKTextureLoaderCallback ([NullAllowed] IMTLTexture texture, [NullAllowed] NSError error);
[Async]
void FromTexture (MDLTexture texture, [NullAllowed] MTKTextureLoaderOptions options, MTKTextureLoaderCallback completionHandler);
```
* Generated code
```
public unsafe virtual Task<global::Metal.IMTLTexture> FromTextureAsync (global::ModelIO.MDLTexture texture, NSDictionary options)
{
var tcs = new TaskCompletionSource<global::Metal.IMTLTexture> ();
> FromTexture(texture, options, (texture, error) => {
if (error != null)
tcs.SetException (new NSErrorException(error));
else
tcs.SetResult (texture);
});
return tcs.Task;
}
```
* Errpr
```
MTKTextureLoader.g.cs(397,35): error CS0136: A local variable named `texture' cannot be declared in this scope because it would give a different meaning to `texture', which is already used in a `parent or current' scope to denote something else
```
Note: we are appending, not prepending, a '_' character
Because:
* we don't want to pick up a fight with GetUniqueParamName that already
prepend a '_' in some cases;
* Pre-fixing '_' does not work for parameters names starting with a `@`
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.