Since the native signature doesn't match the managed signature, we need to
manually check the type of each conversion and make sure the required headers
are included.
Extension methods require the containing class' namespace to be in a `using`,
which we can't easily do (currently) for user code, since we hardcode all our `using`s.
So just call the static extension method directly instead of relying on syntax
sugar.
The two functions mono_class_is_nullable and mono_class_get_nullable_param are
private mono symbols, which means we can't call them when using Xamarin.Mac
with libmono from a dynamic library.
Implement a fallback for this case, where we call a managed method when these
functions are not available (and restrict this workaround to Xamarin.Mac only,
since it's not needed for Xamarin.iOS).
On at least one of my devices I get MACaptionAppearanceDisplayType.AlwaysOn,
while the locale is 'en'.
So just allow all valid enum values for the return type.
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
* [registrar] BindAs uses Nullable types so allow them to be registered as NSObjects
BindAsAttribute allows to bind NSValue and NSNumber into more
accurate C# types lyke bool?, int? etc. so we must teach registrar
about this.
* [tests][introspection] Teach intro about BindAs and Nullable types
Introspection will currently fail if BindAs is used, introspection
will report that the incorrect type is registered so we need to skip
this check if Nullable type is found in the signature
* [introspection] Add better type checking instead of totally skipping the type when Nullable type is encountered
Introspection will currently fail if BindAs is used. Introspection
will report that the incorrect type is registered so we need verify
if a Nullable type is found in the signature and check against of
a withelist of BindAs supported types
* Revert "[registrar] BindAs uses Nullable types so allow them to be registered as NSObjects"
This reverts commit 911eab97b7.
* [tests] Add comment about where to find BindAs types
Very occasionally this may happen:
/bin/sh: /Users/builder/data/lanes/5024/08614af6/source/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/Frameworks/Xamarin-debug.framework/Info.plist: No such file or directory
make[4]: *** [/Users/builder/data/lanes/5024/08614af6/source/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/Frameworks/Xamarin-debug.framework/Info.plist] Error 1
which is fixed by using the right dependencies for the Info.plist target.
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
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
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
Rolf Bjarne Kvinge
Alex Soto
Jeffrey Stedfast
Andy Martin
Bernhard Urban
Alex Soto
James Clancey
Nick Berardi
Timothy Risi
Chris Hamons